Skip to content

test(analytics): verify runtime semantics of account-filter integration tests #32

Closed

Description

@cristim

Context

golangci-lint v2 (landed in LeanerCloud/cloud-commitments-cli#1137) type-checks //go:build integration files. This exposed that the internal/analytics integration tests (postgres_analytics_db_test.go, postgres_analytics_integration_test.go) were written against a removed QueryRequest.AccountID API and the old single-string account signatures of QueryByProvider / QueryByService / QueryMonthlyTotals. They had not compiled since the account-filter model changed to AccountUUIDs + AccountExternalIDsByProvider.

A compile-fix PR restores type-checking (so CI Lint passes) by mechanically remapping the removed account arg to:

AccountExternalIDsByProvider: map[string][]string{"aws": {"<acct>"}, "gcp": {"<acct>"}}

for every query call/struct, keyed under both providers the suite uses.

What this issue tracks (NOT done in the compile-fix PR)

These integration tests run only under Docker/testcontainers (CI Lint just type-checks them), so the compile-fix did not verify their runtime behavior. The account-filter area has historically broken silently (see the global lesson: four successive "fixes" merged green while the bug survived because tests filtered the wrong column). So before trusting these tests:

  • Run the suite with Docker (go test -tags=integration ./internal/analytics/) and confirm each t.Run still asserts the intended rows.
  • Verify the AccountExternalIDsByProvider remap matches each test's saved snapshot providers (the blanket {"aws","gcp"} mapping may over- or under-match a block that previously filtered account-wide or by a single provider).
  • Confirm the AccountUUIDs vs AccountExternalIDsByProvider choice is correct per case (snapshots are saved with an external account id, not a UUID).
  • Add at least one assertion that would FAIL if the account filter matched the wrong column (regression guard for the documented trap).

Acceptance

Integration tests pass under Docker AND a deliberately-wrong account filter makes them fail (proving they actually exercise the filter).

Activity

  1. IAmJSD commented on Oct 19, 2026

    @IAmJSD
    Collaborator

    Claiming: working on this

  2. self-assigned this
    on Oct 19, 2026
  3. added a commit that references this issue on Oct 23, 2026
    c777322
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions