SC: Implement sync call trace #1333

linh2931 · 2025-04-07T19:48:48Z

Impements sync call trace. Each individual sync call has a sync_call_trace struct containing all information about the sync call. An action trace has a vector of sync_call_trace for all sync calls happened within the call. The relationship between sync calls are identified by ordinal and sender_ordinal.

console field and condole debug prints will be implemented in a separate PR.

SHiP support is tracked by #1334

Resolves #1216

A sample sync call traces for

 [
  {
    "action_ordinal": 1,
    "creator_action_ordinal": 0,
    "closest_unnotified_ancestor_action_ordinal": 0,
    "receipt": {
      "receiver": "caller",
      "act_digest": "4169266343f52db133bded246813966fb493bf53a4c16ecea999ece1a6ca7f9f",
      "global_sequence": 48,
      "recv_sequence": 1,
      "auth_sequence": [
        [
          "caller",
          3
        ]
      ],
      "code_sequence": 1,
      "abi_sequence": 1
    },
    "receiver": "caller",
    "act": {
      "account": "caller",
      "name": "doit",
      "authorization": [
        {
          "actor": "caller",
          "permission": "active"
        }
      ],
      "data": ""
    },
    "context_free": false,
    "elapsed": 618,
    "console": "before calling callee1before calling callee2",
    "trx_id": "9189869e2c41413775edbaf1721d036dce527ab576a4e883a874d47f9f39bd2b",
    "block_num": 11,
    "block_time": "2020-01-01T00:00:05.000",
    "account_ram_deltas": [],
    "return_value": "",
    "call_traces": [
      {
        "call_ordinal": 1,
        "sender_ordinal": 0,
        "receiver": "callee1",
        "read_only": false,
        "data": "",
        "elapsed": 299,
        "console": "I am callee1",
        "console_markers": [
          12
        ],
        "return_value": "4920616d2063616c6c656531"
      },
      {
        "call_ordinal": 2,
        "sender_ordinal": 1,
        "receiver": "callee11",
        "read_only": false,
        "data": "4920616d2063616c",
        "elapsed": 145,
        "console": "I am callee11",
        "console_markers": [],
        "return_value": "4920616d2063616c6c65653131"
      },
      {
        "call_ordinal": 3,
        "sender_ordinal": 0,
        "receiver": "callee2",
        "read_only": false,
        "data": "",
        "elapsed": 115,
        "console": "I am callee2",
        "console_markers": [],
        "return_value": "4920616d2063616c6c656532"
      }
    ],
    "console_markers": [
      22,
      44
    ]
  }
]

A sample for exception propagation:

[
  {
    "action_ordinal": 1,
    "creator_action_ordinal": 0,
    "closest_unnotified_ancestor_action_ordinal": 0,
    "receiver": "caller",
    "act": {
      "account": "caller",
      "name": "doit",
      "authorization": [
        {
          "actor": "caller",
          "permission": "active"
        }
      ],
      "data": ""
    },
    "context_free": false,
    "elapsed": 677,
    "console": "",
    "trx_id": "9189869e2c41413775edbaf1721d036dce527ab576a4e883a874d47f9f39bd2b",
    "block_num": 11,
    "block_time": "2020-01-01T00:00:05.000",
    "account_ram_deltas": [],
    "except": {
      "code": 3050003,
      "name": "eosio_assert_message_exception",
      "message": "eosio_assert_message assertion failure",
      "stack": [
        {
          "context": {
            "level": "error",
            "file": "cf_system.cpp",
            "line": 14,
            "method": "eosio_assert",
            "hostname": "",
            "thread_name": "unit_test",
            "timestamp": "2025-04-14T21:00:04.716"
          },
          "format": "assertion failure with message: ${s}",
          "data": {
            "s": "eosio_assert by callee11"
          }
        },
        {
          "context": {
            "level": "warn",
            "file": "host_context.cpp",
            "line": 121,
            "method": "execute_sync_call",
            "hostname": "",
            "thread_name": "unit_test",
            "timestamp": "2025-04-14T21:00:04.716"
          },
          "format": "sync call exception ${receiver} <= ${sender} console output: ${console}",
          "data": {
            "receiver": "callee11",
            "sender": "callee1",
            "console": ""
          }
        },
        {
          "context": {
            "level": "warn",
            "file": "host_context.cpp",
            "line": 121,
            "method": "execute_sync_call",
            "hostname": "",
            "thread_name": "unit_test",
            "timestamp": "2025-04-14T21:00:04.716"
          },
          "format": "sync call exception ${receiver} <= ${sender} console output: ${console}",
          "data": {
            "receiver": "callee1",
            "sender": "caller",
            "console": ""
          }
        },
        {
          "context": {
            "level": "warn",
            "file": "apply_context.cpp",
            "line": 124,
            "method": "exec_one",
            "hostname": "",
            "thread_name": "unit_test",
            "timestamp": "2025-04-14T21:00:04.716"
          },
          "format": "${receiver} <= ${account}::${action} console output: ${console}",
          "data": {
            "console": "",
            "account": "caller",
            "action": "doit",
            "receiver": "caller"
          }
        }
      ]
    },
    "error_code": "10000000000000000000",
    "return_value": "",
    "call_traces": [
      {
        "call_ordinal": 1,
        "sender_ordinal": 0,
        "receiver": "callee1",
        "read_only": false,
        "data": "",
        "elapsed": 478,
        "console": "",
        "console_markers": [
          0
        ],
        "except": {
          "code": 3050003,
          "name": "eosio_assert_message_exception",
          "message": "eosio_assert_message assertion failure",
          "stack": [
            {
              "context": {
                "level": "error",
                "file": "cf_system.cpp",
                "line": 14,
                "method": "eosio_assert",
                "hostname": "",
                "thread_name": "unit_test",
                "timestamp": "2025-04-14T21:00:04.716"
              },
              "format": "assertion failure with message: ${s}",
              "data": {
                "s": "eosio_assert by callee11"
              }
            },
            {
              "context": {
                "level": "warn",
                "file": "host_context.cpp",
                "line": 121,
                "method": "execute_sync_call",
                "hostname": "",
                "thread_name": "unit_test",
                "timestamp": "2025-04-14T21:00:04.716"
              },
              "format": "sync call exception ${receiver} <= ${sender} console output: ${console}",
              "data": {
                "receiver": "callee11",
                "sender": "callee1",
                "console": ""
              }
            },
            {
              "context": {
                "level": "warn",
                "file": "host_context.cpp",
                "line": 121,
                "method": "execute_sync_call",
                "hostname": "",
                "thread_name": "unit_test",
                "timestamp": "2025-04-14T21:00:04.716"
              },
              "format": "sync call exception ${receiver} <= ${sender} console output: ${console}",
              "data": {
                "receiver": "callee1",
                "sender": "caller",
                "console": ""
              }
            }
          ]
        },
        "error_code": "10000000000000000000",
        "return_value": ""
      },
      {
        "call_ordinal": 2,
        "sender_ordinal": 1,
        "receiver": "callee11",
        "read_only": false,
        "data": "0000000000000000",
        "elapsed": 305,
        "console": "",
        "console_markers": [],
        "except": {
          "code": 3050003,
          "name": "eosio_assert_message_exception",
          "message": "eosio_assert_message assertion failure",
          "stack": [
            {
              "context": {
                "level": "error",
                "file": "cf_system.cpp",
                "line": 14,
                "method": "eosio_assert",
                "hostname": "",
                "thread_name": "unit_test",
                "timestamp": "2025-04-14T21:00:04.716"
              },
              "format": "assertion failure with message: ${s}",
              "data": {
                "s": "eosio_assert by callee11"
              }
            },
            {
              "context": {
                "level": "warn",
                "file": "host_context.cpp",
                "line": 121,
                "method": "execute_sync_call",
                "hostname": "",
                "thread_name": "unit_test",
                "timestamp": "2025-04-14T21:00:04.716"
              },
              "format": "sync call exception ${receiver} <= ${sender} console output: ${console}",
              "data": {
                "receiver": "callee11",
                "sender": "callee1",
                "console": ""
              }
            }
          ]
        },
        "error_code": "10000000000000000000",
        "return_value": ""
      }
    ],
    "console_markers": [
      0
    ]
  }
]

…l tests later

spoonincode · 2025-04-08T16:12:59Z

libraries/chain/include/eosio/chain/trace.hpp

      std::optional<fc::exception>    except;
      std::optional<uint64_t>         error_code;
      std::vector<char>               return_value;
+      std::optional<std::vector<sync_call_trace>>  call_traces;


Why an optional vector? I'm guessing you don't want call_traces to appear in JSONified trace if an action didn't use sync calls at all?

Yes, that is what I want. Should we show call_traces with an empty "" instead if an action did not make any sync calls? @arhag

Wouldn't an empty vector be sufficient to unambiguously indicate the action didn't use sync calls at all?

I don't see the harm of always including the call_traces in the JSON output of the action trace with it being [] if no sync calls were made.

Thank you both. I will change to use plain vector.

…onal vector of call_trace

…aces in abi_test

spoonincode · 2025-04-09T22:20:20Z

libraries/chain/include/eosio/chain/trace.hpp

+
+      uint32_t                      ordinal = 1;
+      const uint32_t                sender_ordinal = 0;
+      const account_name            sender;


Is sender redundant information since you have sender_ordinal?

I put sender here for simple reference. But it can be found from sender_ordinal. Will remove it.

spoonincode · 2025-04-09T22:21:13Z

libraries/chain/include/eosio/chain/trace.hpp

+      string                        console;
+      std::optional<fc::exception>  except;
+      std::optional<uint64_t>       error_code;
+      int64_t                       return_value_size_or_error_id = 0; // if >=0: return value size, if -1: receiver not supporting sync calls


The return value size is redundant information since it's already implicitly part of the return_value. I am not sure how to best handle the validity of this and other items in the trace. It almost seems like really we have a variant made up of

contract was runnable: elapsed, console, except,error_code, return_value

contract was not runnable error_id (i.e. reason it wasn't runnable)

But using a variant here may be quite the departure from precedent.

I was struggling about this too. I would replace return_value_size_or_error_id with an optional error_id. If a contract is runnable, this field is not presented. If a contract is not runnable, this field shows up with reasons., while elapsed, console, except, error_code, and return_value are empty.

spoonincode · 2025-04-09T22:23:35Z

libraries/chain/include/eosio/chain/trace.hpp

+      const uint32_t                sender_ordinal = 0;
+      const account_name            sender;
+      const account_name            receiver;
+      const uint64_t                flags = 0;


Does it make any sense to "unwrap" the flags in the user visible trace? For example instead of a consumer just seeing flags: 1 or flags: 2 and needing to know what the magic numbers are, they'd see for example

"read_only": false, "some_other_flag": true

Good idea. I will unwrap it.

One consideration is, if we use new bits in the future, we will need to add them to the call trace. But that should be OK as it is a protocol change.

That is true... I suppose it would be most disruptive for SHIP since it would require a whole new sync_call_trace_vx whenever a new flag is added.

spoonincode

Adding a few comments on structure of user visible trace that has been nagging me -- I'm not really sure what the correct solution is for some of these. Especially whether there is precedence to lean in to for inconsistency or not.

spoonincode · 2025-04-10T02:05:28Z

btw couldn't find any issue/task for adding the traces to trace_api_plugin, though the design doc does say that traces will be added there.

linh2931 · 2025-04-10T14:35:55Z

btw couldn't find any issue/task for adding the traces to trace_api_plugin, though the design doc does say that traces will be added there.

Thanks. I forgot to create one. Here is now #1348

linh2931 · 2025-04-10T14:37:23Z

Adding a few comments on structure of user visible trace that has been nagging me -- I'm not really sure what the correct solution is for some of these. Especially whether there is precedence to lean in to for inconsistency or not.

I will add some comments about the new struct and its fields to help users.

spoonincode · 2025-04-10T20:12:10Z

libraries/chain/include/eosio/chain/trace.hpp

+      uint32_t                      ordinal = 1;
+
+      // sender's ordinal. If the caller is the action, sender_ordinal is 0.
+      const uint32_t                sender_ordinal = 0;


I should have noticed this sooner -- I think we'd want to make these varints (fc::unsigned_int). Ordinals in action_trace are also varints.

Thanks. Will change.

spoonincode · 2025-04-10T20:12:27Z

libraries/chain/include/eosio/chain/trace.hpp

+   struct console_marker {
+      uint32_t call_ordinal     = 0;
+      uint32_t console_position = 0;
+   };


Probably varint for these too

spoonincode · 2025-04-10T20:18:19Z

libraries/chain/include/eosio/chain/trace.hpp

+   // Identify the starting position of a sync call in the call's console log.
+   // This is used for pretty printing console logs.
+   struct console_marker {
+      uint32_t call_ordinal     = 0;


When discussed on call I thought we came to the conclusion we only needed the position? i.e. type could be vector<unsigned_int> console_markers and the size of console_markers is the number of sync calls performed I think¹. Can we still do it that way or was there a challenge with it?

Footnotes

I seem to remember us saying number of sync calls minus 1 but that isn't making sense to me immediately 🤔 ↩

I thought using the struct was more clear. But will change to one dimensional vector to save space, as this is to be used by SHiP. n-1 should be OK as we know the start and end.

Hm, when I started to change the code, it seemed to me we need n instead of n-1. Did I miss something?

If we have n sync calls, we should have n points to indicate where in the console we start the calls.

If we make only 1 sync call, I think we still need 1 marker, not 0.

I think you are correct @linh2931.

…with action_trace

…ordinal and to be consistent with action_ordinal in action_trace

spoonincode · 2025-04-14T17:55:07Z

libraries/chain/apply_context.cpp

            }
         }
-      } FC_RETHROW_EXCEPTIONS( warn, "${receiver} <= ${account}::${action} pending console output: ${console}", ("console", _pending_console_output)("account", act->account)("action", act->name)("receiver", receiver) )
+      } FC_RETHROW_EXCEPTIONS( warn, "${receiver} <= ${account}::${action} console output: ${console}", ("console", trx_context.get_action_trace( action_ordinal ).console)("account", act->account)("action", act->name)("receiver", receiver) )


It might be nice to have a get_current_action_trace() or such, since this trx_context.get_action_trace( action_ordinal ) is used all over. Obviously not critical to do.

Thanks! I renamed get_root_action_trace() (I did not like the name when I initially named it) with get_current_action_trace(), and replaced direct use of trx_context.get_action_trace( action_ordinal ) with get_current_action_trace(). The code looks nicer.

26fbb7b

spoonincode · 2025-04-14T18:00:30Z

libraries/chain/host_context.cpp

+   // As early as possible, create the call trace of this new sync call in the parent's
+   // (sender's) trace to record entire trace of the sync call, including any exceptions
+   auto& trace = get_root_action_trace();
+   const bool read_only = flags & static_cast<uint64_t>(sync_call_flags::read_only);


In an earlier PR we discussed using has_field() not sure how much it matters

Because the last element all_allowed_bits in the enum sync_call_flags is not a flag (or field in a sense). I did not use the has_field mechanism. Will revisit this later.

spoonincode · 2025-04-14T18:06:12Z

libraries/chain/host_context.cpp

+      auto& call_trace = get_call_trace(ordinal);
+      call_trace.error_id = -1;
+      finalize_call_trace(call_trace, start);
+      trx_context.checktime();


Probably not strictly necessary -- since no new WASM was run in this case, the expiration handlers weren't touched and we didn't run a risk of missing an expiration. Fine to keep as is since we may need to take more of a look on how expiration works in the future

spoonincode · 2025-04-14T18:07:38Z

libraries/chain/host_context.cpp

-            // TBD store the info in sync call trace
-            ilog("receiver_account->code_hash empty");
-            return return_value_size;
+            return handle_call_failure();


In this case the console marker will not be created. Seems like creation of console marker should be moved way up earlier in the function

I put it here thinking if we could not make a sync call for any reasons before creating the sync call context, we should not put the sync call position in the markers, since no call was made.

No call was made but you added a trace for the call still. That means it becomes impossible to use the markers properly because the number of markers will not equal the number of sync call traces

Yes, you are right. I will put them together.

spoonincode · 2025-04-14T18:26:01Z

libraries/chain/host_context.cpp

            // store return value
            last_sync_call_return_value = std::move(call_ctx.return_value);
            return_value_size = last_sync_call_return_value.size();
         } catch( const wasm_exit&) {}


Not new to this PR but I realize here that if a contract sets return value then eosio_exits it looks like the return value is lost. Worse then that, highly likely there is a JIT vs OC difference here. Can make new issue for this but we need to track it some how if not fixed here.

spoonincode · 2025-04-14T18:36:06Z

libraries/chain/include/eosio/chain/sync_call_context.hpp

 class sync_call_context : public host_context {
 public:
-   sync_call_context(controller& con, transaction_context& trx_ctx, account_name sender, account_name receiver, bool privileged, uint32_t sync_call_depth, uint64_t flags, std::span<const char> data);
+   sync_call_context(controller& con, transaction_context& trx_ctx, uint32_t oridnal, action_trace& root_action_trace, account_name sender, account_name receiver, bool privileged, uint32_t sync_call_depth, uint64_t flags, std::span<const char> data);


spelling on ordinal

spoonincode · 2025-04-14T18:47:06Z

I think these 3 should be addressed but otherwise LGTM
#1333 (comment)
#1333 (comment)
#1333 (comment)

spoonincode · 2025-04-14T18:48:07Z

Also probably want to update the PR description with the new trace format. But there is plenty other documentation that will need to be updated one day too

…direct use of trx_context.get_action_trace( action_ordinal ) with get_current_action_trace()

… number of markers matches with the number of call traces

linh2931 · 2025-04-14T21:03:04Z

Also probably want to update the PR description with the new trace format. But there is plenty other documentation that will need to be updated one day too

I updated the PR description with the new trace format. It looks quite nice!

Yes, we will write good documentation when the feature is done.

linh2931 · 2025-04-14T21:06:32Z

I think these 3 should be addressed but otherwise LGTM #1333 (comment) #1333 (comment) #1333 (comment)

They have been addressed. Thanks!

…output

libraries/chain/apply_context.cpp

libraries/chain/host_context.cpp

libraries/chain/include/eosio/chain/abi_serializer.hpp

heifner · 2025-04-16T18:47:56Z

libraries/chain/include/eosio/chain/abi_serializer.hpp

         } catch(...) {}
+
+         mvo("call_traces", act_trace.call_traces);
+         mvo("console_markers", act_trace.console_markers);


This doesn't seem right to me. The abi_serializer job is to produce the data in clean JSON. This will be a list of ints which doesn't seem that easy to understand. It is not clear to me what would be better. Maybe insert [[call_trace identifer - BEGIN]] [[call_trace identifer - END]] into the console output and remove the console_markers output.

We talked about this in multiple daily standups and afaict it matches what was agreed upon? If the JSON (not what cleos pretty prints) needs to be easier to manually grok we should discuss it again and come up with a new approach.

That is true, we did discuss this. Seeing it in practice makes me think it is less than ideal. But the alternative of parsing the JSON console string is not great either. I withdraw my comment.

The only immediate thought I have is to change the console logs to be a vector<variant<string, varint>>. So the effective output is something like

"console": ["console output before a sync call", 1, "some stuff between two sync calls", 2, "after doing a couple sync calls"]

The numbers being the sync call ordinals.

Now of course if you output vector<variant<string, varint>> through standard variant mechanism it won't look like that. However, we're already "manually" crafting the trace's JSON for ABI stuff! So it isn't a stretch to go ahead and collapse the variant to the appropriate JSON types so it does look that nice as above. This does make the outputted JSON impossible to ingest through ABI again though, but I can't see any immediate reason that's a problem?

Of course the traces in ship would need to remain a proper variant<string, varint> which does introduce an inconsistency, at least technically. But ship never does ABI deserialization either so it's already not going to be exactly what the trace was from the node.

idk if it's worth it -- but I do believe it would improve readability some.

We also would still have the challenge of what to do about current console in action trace (the current approach is nice in that it doesn't touch it at all)

I'm also not sure it is worth it. But that could also be:

"console": ["console output before a sync call", "some stuff between two sync calls", "after doing a couple sync calls", "", "after another sync call with no logging in between"]

Then it would be representable in ABI.

I think it is fine as is.

I would rather not change the existing console field to not break any consumers that currently expect it as a string.

…er()

Implement sync call trace

8fe4c0a

linh2931 requested review from heifner and spoonincode April 7, 2025 19:48

linh2931 linked an issue Apr 7, 2025 that may be closed by this pull request

SC: Add sync_call traces to call traces #1216

Closed

linh2931 added 2 commits April 7, 2025 16:20

Update deep-mind.log

2dc7058

Temporarily add a dummy sync_call_traces to abi_tests; will add actua…

3deca95

…l tests later

linh2931 mentioned this pull request Apr 7, 2025

SC: Need a new status code -2 to call host function to indicate the receiver's contract is empty; trx_context.checktime() needs to be called at every return point #1324

Closed

Merge branch 'sync_call' into call_trace

0519778

spoonincode reviewed Apr 8, 2025

View reviewed changes

linh2931 added 2 commits April 8, 2025 14:52

Change call_traces to be a plain vector of call_trace instead of opti…

0924f32

…onal vector of call_trace

Correct a typo in abi_serializer and update to use vector for call_tr…

73eca15

…aces in abi_test

spoonincode reviewed Apr 9, 2025

View reviewed changes

linh2931 added 2 commits April 9, 2025 21:08

Remove sender from call_trace

3038697

Replace return_value_size_or_error_id with an optional error_id

69d62d1

linh2931 added 3 commits April 10, 2025 14:04

Present the contents of flags explicitly

f592a81

Add console_markers to help identify relative console log positions

821e044

Add detailed comments about new sync_call_trace fields

78e1a14

spoonincode reviewed Apr 10, 2025

View reviewed changes

linh2931 added 4 commits April 10, 2025 16:49

Use varints for ordinals

42b414b

Update abi test

378aa24

update deep-mind.log

7967fab

Use one-dimensional vector for console_markers

c4435f0

linh2931 and others added 4 commits April 11, 2025 15:31

Implement console log and console markers for sync calls

c9ad8e1

Rename sync_call_trace to call_trace to be concise and be consistent …

b8dad24

…with action_trace

Rename ordinal with call_ordinal to better differentiate with sender_…

d6e6d43

…ordinal and to be consistent with action_ordinal in action_trace

Merge branch 'sync_call' into call_trace

f136bcd

spoonincode approved these changes Apr 14, 2025

View reviewed changes

Rename get_root_action_trace to get_current_action_trace and replace …

26fbb7b

…direct use of trx_context.get_action_trace( action_ordinal ) with get_current_action_trace()

linh2931 mentioned this pull request Apr 14, 2025

SC: lost return value when eosio_exit is called #1372

Closed

linh2931 added 2 commits April 14, 2025 16:23

Store console marker right after call trace was created such that the…

b361003

… number of markers matches with the number of call traces

Fix a typo

9318fe4

add prints to a test

6bcac16

Add more prints to trace_nested_and_sequential_test for sample trace …

ce273fc

…output

heifner suggested changes Apr 16, 2025

View reviewed changes

heifner mentioned this pull request Apr 16, 2025

SC: Support the new call section in ABI #1220

Closed

linh2931 and others added 6 commits April 17, 2025 13:23

Fix a typo in comments

4390645

Do the check of control.contracts_console() inside store_console_mark…

af07be8

…er()

Merge branch 'sync_call' into call_trace

b175556

Fix a merging error

70ebd31

Add back a missing eos_vm_oc check during merging

045767a

Merge branch 'sync_call' into call_trace

4fd5a8c

spoonincode mentioned this pull request Apr 18, 2025

SC: Support read only sync call #1404

Merged

linh2931 mentioned this pull request Apr 18, 2025

SC: Make sure read-only flags in call_traces are consistent #1408

Closed

Merge branch 'sync_call' into call_trace

00b2b97

spoonincode mentioned this pull request Apr 23, 2025

SC: Add sync calls to deep mind log #1439

Merged

heifner approved these changes Apr 23, 2025

View reviewed changes

linh2931 merged commit e4a8372 into sync_call Apr 23, 2025
36 checks passed

linh2931 deleted the call_trace branch April 23, 2025 23:33

SC: Implement sync call trace #1333

SC: Implement sync call trace #1333

Uh oh!

Conversation

linh2931 commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spoonincode Apr 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spoonincode left a comment

Choose a reason for hiding this comment

Uh oh!

spoonincode commented Apr 10, 2025

Uh oh!

linh2931 commented Apr 10, 2025

Uh oh!

linh2931 commented Apr 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

linh2931 Apr 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

linh2931 commented Apr 7, 2025 •

edited

Loading

spoonincode Apr 9, 2025 •

edited

Loading

linh2931 Apr 10, 2025 •

edited

Loading