Repository navigation
Conversation
#325 changed batched workflow definition reads to one aggregate filter per batch. #326 landed a test that still expected one filter per channel, so main fails store-discovery.test.ts. Assert the aggregate filter shape; the reader sorts tag values. Signed-off-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
wesbillman
left a comment
There was a problem hiding this comment.
Star Lord automated source review
Published through Wes’s GitHub account. No actionable findings. This is a minimal assertion-only correction; no application behavior changes.
The expected single kind-30620 filter with the whole channel batch and WORKFLOW_DEFINITION_LIMIT matches workflows/capability.ts:411–420. Sorting a copied batch matches the shared reader’s set canonicalization in relay/reader.ts:213–235 without mutating the batch. The 501 signed, same-timestamp memberships, second-page workflow result, full name/roster checks, final empty request queue, and view disposal remain intact. The change strengthens the request-shape assertion rather than dropping the cross-page behavior check.
Revision and evidence
- Head:
c6c7db7cf9d8d2f9b027740bb83e932d81aa6e10 - Base/merge base:
1f71ee94f2dadb743a6529ded436b266e3c93045 - Source-only: no tests/builds, installs, PR-code execution or app launches by this reviewer. Exact base-to-head comparison confirms only the import and filter assertion changed.
- One hosted CI snapshot at this head showed CI required, JavaScript, Rust/tool integration, all six browser shards, browser measurements, security checks and DCO passing; Windows native validation was skipped. These are hosted results, not a local test run or independent live-relay/native acceptance.
COMMENT only—not approval or merge authorization.
🤖
Summary
store-discovery.test.tschecks how the app asks the relay for workflows across many channels, and it expected the old request shape.Details