Skip to content

[2/N] [List API] feat(storage): add request summary read model#303

Open
albertywu wants to merge 1 commit into
wua/list-api-request-logfrom
wua/list-api-summary-store
Open

[2/N] [List API] feat(storage): add request summary read model#303
albertywu wants to merge 1 commit into
wua/list-api-request-logfrom
wua/list-api-summary-store

Conversation

@albertywu

@albertywu albertywu commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds the RequestSummary entity, storage contract, generated mocks, and MySQL implementation for the gateway-owned list read model. The store merges immutable request-log events into a queue-scoped summary table with optimistic concurrency.

Test Plan

make fmt && make build && make test && make check-mocks && make e2e-test

Issues

Stack

  1. [1/N] [List API] feat(requestlog): persist queue and change metadata #302
  2. @ [2/N] [List API] feat(storage): add request summary read model #303
  3. [3/N] [List API] feat(gateway): expose request List RPC #304
  4. [4/N] [List API] test(e2e): cover gateway List API #305
  5. [5/N] [List API] docs(service): document gateway List API #306

@albertywu albertywu force-pushed the wua/list-api-request-log branch from e8b3462 to e60d532 Compare July 7, 2026 00:22
@albertywu albertywu force-pushed the wua/list-api-summary-store branch 2 times, most recently from 552ce82 to 419a487 Compare July 7, 2026 00:40
@albertywu albertywu force-pushed the wua/list-api-request-log branch 2 times, most recently from 4255521 to bf69e42 Compare July 7, 2026 00:46
@albertywu albertywu force-pushed the wua/list-api-summary-store branch from 419a487 to 4980cb0 Compare July 7, 2026 00:46
@albertywu albertywu marked this pull request as ready for review July 7, 2026 01:42
@albertywu albertywu requested review from a team, behinddwalls and sbalabanov as code owners July 7, 2026 01:42
Summary:

Adds the RequestSummary entity, storage contract, generated mocks, and MySQL implementation for the gateway-owned list read model. The store merges immutable request-log events into a queue-scoped summary table with optimistic concurrency.

Test Plan:

✅ `make fmt && make build && make test && make check-mocks && make e2e-test`
// event — invalidates the read, in which case we re-read and re-merge. Merges are monotonic (the
// winner only advances by request version or timestamp), so the loop converges; re-applying a log
// that has already been merged is a no-op.
func (s *requestSummaryStore) UpsertFromLog(ctx context.Context, log entity.RequestLog) (retErr error) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally this is purely a write to DB, like any other store with CAS, any logic to summarize should live in the request logs consumer controller, we can event thing of adding more queues if needed post persisting requestLog to summarize and do any other things as needed. But we can start with requestlog controller itself

Comment on lines +57 to +58
StartedAtMs int64
RequestID string

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need both or just the last RequestID we returned as cursor?

StartedAtMs int64
UpdatedAtMs int64
CompletedAtMs int64
Terminal bool

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need this? should the status be enough to reflect whether it's terminal or not

@albertywu albertywu changed the title feat(storage): add request summary read model [2/N] [List API] feat(storage): add request summary read model Jul 7, 2026
if err := store.GetRequestLogStore().Insert(ctx, log); err != nil {
return fmt.Errorf("failed to insert request log for request_id=%s: %w", log.RequestID, err)
}
_ = store.GetRequestSummaryStore().UpsertFromLog(ctx, log)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's not swallow errors

completed_at_ms BIGINT NOT NULL,
terminal BOOLEAN NOT NULL,
version BIGINT NOT NULL,
PRIMARY KEY (queue, request_id)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what queries will be executed on this table?
if we filter by queue and status (i.e. executing or completed) then it will do partial table scan which is inefficient

EndTimeMs int64
Statuses []entity.RequestStatus
Sort RequestSummarySort
Cursor *RequestSummaryCursor

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why pointer?

Sort RequestSummarySort
Cursor *RequestSummaryCursor
Limit int
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok now I see a list of criteria. If we intend to keep request log records for each queue indefinitely, the index has to be redesigned. Right now it will do full scan for pretty much all of the query parameters.
If we always sort by the same field, it should be included in the index to at least do paginated index scan.

// RequestSummaryListOptions defines a page-in request for RequestSummaryStore.
type RequestSummaryListOptions struct {
Queue string
StartTimeMs int64

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please comment specification, what values to set to what result to expect. How to specify that filtering should not be done by a particular field, or should it always specify arbitrary big/small values?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants