3

For an individual transaction, how would you be able to relate a log to its corresponding set of instructions? I'm having difficulty finding a way to identify which logs belong to an instruction, especially in instances where there are nested inner instructions.

ie example instruction and logs for a transactions:

instruction 1
instruction 2
   -inner instruction 1
   -inner instruction 2
instruction 3
   -inner instruction 1
   -inner instruction 2

logs:

log a
log b
log c
log d
log e

...

How would you be able to identify that log x is related to instruction x? I noticed that some logs have an index (ie. "Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [2]") but am not entirely sure if that maps to an instruction in some way.

2 Answers 2

4

Instructions in a transaction are processed in order. So the order you add the instruction to the transaction is the order the of the program logs. You can also use msg!("Some Message") to add additional Program Logs in your instructions.

Image is example of program logs for a transaction with multiple instructions enter image description here

1

When a program emits logs inside of a transaction, each log is effectively just added to a single, flat array of strings. So in order to actually determine the instruction that caused a program to emit a specific log is sort of difficult.

The way that the Solana explorer parses and display a transaction's logs is probably the best way to do. The explorer's parsing takes a few assumptions in its parsing:

  • all the transaction logs are a simple array of strings
  • each "simple string" log contains the address of the program that created the log (this is true because how the Solana rust code actually formats the logs)
  • instructions within a Solana transaction are executed atomically (i.e. in order). this is how the Solana runtime is designed and always true
  • at the completion of each program execution, there will always be a "success" message (the runtime does this automatically, and does not require the program developer to add this message). (this is the the message to pay extra attention too when processing the logs)

So if you loop over the simple array of string log values (type String[]):

  • each log will have the program (programId) that executed it towards the beginning of the string
  • when the programId changes, you know the runtime is processing a different program
  • when the log is a "success" log, you know the program completed successfully. aka the instruction completed successfully (either the cpi or the non-cpi instructions)

Using this knowledge, you can loop over the array of string values, parsing out the instructions from a specific program and specific instruction within a transaction.

Note: there is potentially an edge case not covered by the explorer's parser. I believe that if a program decides to send extra logs that look like they were formatted similar enough, it could trick the explorer's simple parser to miss display the logs in the UI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.