Skip to content

class_counts is the one unbounded axis of the review payload #11

Description

@jakewan

Rows are bounded by limit/maxLimit (internal/server/review.go:39) and text by observationTextCap (:45), with :36-38 reasoning explicitly about the SDK's double serialization. Nothing bounds the class tally: store.List groups over the entire filtered match (internal/store/store.go:465-466), so every distinct class in the match lands in the result even at limit=1.

Classes are caller-defined free-form strings the recording invariant forbids rejecting, so cardinality is not something the server controls. A client coining a novel class per call grows class_counts to the table's class cardinality on every review.

TestReviewClassCountsSpanTheWholeMatch pins the spanning behavior at cardinality 2 — the property that makes it useful is the same one that makes it unbounded, so this is a contract judgment call rather than a plain bug fix.

Direction: cap the tally and flag it, consistent with how rows and text already behave, or document the cardinality assumption in the tool description.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions