Conversation
✅ API Diff Results -
|
c890fb8 to
16775bb
Compare
| return nil | ||
| } | ||
|
|
||
| func generateTracingIDForOCR2(configDigest ocrtypes.ConfigDigest, epoch uint32, round uint8) string { |
There was a problem hiding this comment.
Could make sense to add a quick test for this function, just to be 100% sure
| if meta != nil && meta.TracingID != nil { | ||
| return *meta.TracingID | ||
| } | ||
| return "" |
There was a problem hiding this comment.
Maybe unknown is clearer? It will differentiate it from the error case
There was a problem hiding this comment.
I don't think unknown is consistent. I'd rather have it empty, or probably not log the field at all if it's nil in a future PR.
There was a problem hiding this comment.
Fair, I do think it would be nice to differentiate between the unknown/unset situation and the error situation though
There was a problem hiding this comment.
Sure, but we shouldn't relay an error in an unrelated log field just because the underlying method happened to fail. That was the intention of the error log above. Each time you'll make the call you'll see the empty field but you'll also see the failed to get meta of the transaction message. If you feel there is a better way to handle this, happy to discuss.
There was a problem hiding this comment.
I'm not completely following this. Let's say we grep the logs for broadcasted transactions by querying e.g. <logs> |= "Broadcasted attempt". We will then see a number of broadcasts with their tracing ID attached. Then we can do a new search with <logs> | tracingID="<tracingID>".
However, if tracing ID is empty, then we don't know what happened: is it actually not set or were we unable to retrieve Meta? We won't see the failed to get meta of the transaction log line because we've already scoped the query to Broadcasted attempt.
Anyway, I'm fine leaving it like this since there's a very low chance GetMeta() returns an error, this would only happen on malformed json.
There was a problem hiding this comment.
Yes, if you filter specifically with <logs> |= "Broadcasted attempt" you won't see it, but if you filter for the TXM logs, which is usually what we do, you'll be able to see a bunch of errors explaining the issue. If you're expecting a tracingID value and it's not there it's somewhat easy to infer what happened. Overall, I see the point, it's just I don't want to pollute the implementation with a custom handling for such an edge case, while we can retrieve the information by another log
There was a problem hiding this comment.
Also this might be eventually split up to individual fields i.e. configDigest, epoch, round
There was a problem hiding this comment.
That's true. Ok let's leave it like this
pkg/txm/types/transaction.go
Outdated
| return &m, nil | ||
| } | ||
|
|
||
| func (t *Transaction) GetTracingID(lggr logger.SugaredLogger) string { |
There was a problem hiding this comment.
Unfortunate that we have to pass the logger but I also don't see any better option
There was a problem hiding this comment.
Yes, I struggled to find a good way to do this, but v1's GetMeta already does that so I just went with it.
| select { | ||
| case triggerCh <- struct{}{}: | ||
| default: | ||
| } |
There was a problem hiding this comment.
Can't fully oversee the consequences of this change, can you explain this a bit?
There was a problem hiding this comment.
Yes, this is the default way in go to not block the caller and just fill the channel and exit. Before we would (mistakenly) block after the buffer was filled. The old way may impact throughput on some rare cases, hence the change.
912d9bf to
d9b80dd
Compare
There was a problem hiding this comment.
Pull request overview
Adds a transaction tracing ID to support end-to-end correlation from OCR transmit through TXM lifecycle and dual-broadcast relaying.
Changes:
- Introduces
TracingIDin TX meta and helpers to extract/log it across TXM components. - Updates TX string formatting/tests to avoid double-escaped meta fields in structured logs.
- Generates and attaches an OCR2-derived tracing ID in the dual contract transmitter; bumps
chainlink-framework/chainsdependency.
Reviewed changes
Copilot reviewed 7 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/txm/types/transaction.go | Adds TracingID to TxMeta, improves Transaction.String(), and introduces GetTracingID. |
| pkg/txm/types/transaction_test.go | Extends tests to validate string/meta formatting and JSON-encoding behavior in logs. |
| pkg/txm/txm.go | Logs tracing IDs on create/broadcast/confirm; makes trigger signaling non-blocking. |
| pkg/txm/clientwrappers/dualbroadcast/meta_client.go | Includes tracing ID in dual-broadcast interception log. |
| pkg/transmitter/dual_contract_transmitter.go | Generates OCR2 tracing IDs, attaches them to tx meta, and logs transmit/create events. |
| pkg/transmitter/dual_contract_transmitter_test.go | Adds unit test for OCR2 tracing ID generation. |
| go.mod | Bumps chainlink-framework/chains version. |
| go.sum | Updates checksums for the bumped dependency. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } | ||
|
|
||
| func generateTracingIDForOCR2(reportTimestamp ocrtypes.ReportTimestamp) string { | ||
| return fmt.Sprintf("0x%s:%d:%d", reportTimestamp.ConfigDigest.Hex(), reportTimestamp.Epoch, reportTimestamp.Round) |
There was a problem hiding this comment.
the config digest captures the aggregator address right?
There was a problem hiding this comment.
Not directly, but it's encapsulated.
augustbleeds
left a comment
There was a problem hiding this comment.
what's the main debugging path you'll use for this -- figuring out what happened to transmissions where primary succeeded but secondary failed?
Two things:
|
This PR adds TransactionLifecycleID to txmv2 and enables it both for v1 and v2 for the dual broadcast relayer.