Review comments/questions on the API implementation

Schema

1. Action/Event output: ActionStates in the schema here corresponds to the account state after all the transactions in a block is applied. is the assumption that the values in ActionStates corresponds to each set of actions per transaction?

Output types

1. Remove accountUpdateId from ActionData. This refers to the database primary key. Consider replacing it with account ID and computed sequence number of the corresponding account update in the transaction
2. Similarly for EventData. In fact, there are 2 more orderings from here- For each account update there is a list of actions/events and each action is an array of field elements. Refer to the ordering issue here (Issue)

Queries

1. Nit: blocksAccessedCTE is more like bocksFiltered
2. I'm not sure if the filtering in emittedActionStateCTE makes sense. When would one want to retrieve field elements within a certain range? afaiu you'd need the action state value from the DB to confirm the order of actions applied. Filtering based on account and block height seems sufficient. Also the current implementation here isn't seem right https://github.com/o1-labs/Archive-Node-API/blob/1bad4d3f8d23025cc2f8dc268aa85f438d4fed9f/src/db/sql/events-actions/queries.ts#L192. The comparison is using primary key field

Error handling

1. fullChainCTE: Add missing block checks. Any gaps will go unnoticed wherever this is used and affect the final result in unexpected ways

Start by reading the API schema and src/db/sql/events-actions/queries.ts, especially blocksAccessedCTE, emittedActionStateCTE, and fullChainCTE. Check the linked ordering issue and compare the current ActionData, EventData, and ActionStates behavior with the requested account and transaction ordering. Done means the schema, query naming and filtering, and missing-block handling match the review requirements.