fix: repair silently failing selector tests, guard premature campaign completion, build for the target arch - #12
Conversation
Four selector tests have been failing silently since the v2.0 switch to the persisted-hash GameDirectory query: production now passes the game's URL slug to GetGameStreamsDropsEnabled, while the test fixtures are keyed by display name. The fake returned no streams, so buildPool produced an empty pool and the assertions never had anything to work with. Affected: TestBuildPool_UnrestrictedCampaign, TestBuildPool_DirectoryQueriedOncePerGame, TestSelect_WantedGamesForcesNonClosestExpiry, TestSelect_SkipChannelsExcludesFromPool. The fake now falls back to matching SlugFromGameName(fixtureKey) against the requested slug, and counts the call under the fixture key so the "queried once per game" assertion keeps working. Fixtures stay readable (display names), no production code touched.
autoClaimWith() marked a campaign completed as soon as every drop it could
see was claimed. Twitch sometimes omits requiredMinutesWatched for a
campaign's later drops, so after claiming drop 3 of 5 the loop sees
"everything claimed", writes the campaign to completed_campaigns, and the
selector filters it out permanently — the remaining two drops are abandoned
mid-progress. Observed on a 5-tier Marble Day campaign.
Completion now additionally requires:
- !c.InInventory — while Twitch still lists the campaign as in-progress
there is more to farm. This is the same anchor
MarkCompletedIfFinishedExternally already trusts, so the two paths agree.
- claimedSeen > 0 — a campaign whose metadata glitched to "nothing
watchable" cannot complete itself without a single observed claim.
No farming loop is introduced by waiting: a genuinely finished campaign that
is still in the inventory is skipped by the selector anyway (no drop reports
IsEarnable), and gets marked on a later cycle once Twitch drops it from the
in-progress list.
The Dockerfile hard-coded GOARCH=amd64, so the image could only ever run on
x86-64 — building on or for arm64 (Raspberry Pi, Apple Silicon, arm64 servers)
produced an amd64 binary that fails to start. The release workflow already
publishes a twitchpoint-linux-arm64 binary, so the Docker image was the only
place still pinned.
GOOS/GOARCH now come from TARGETOS/TARGETARCH, which BuildKit sets
automatically. Behaviour is unchanged for existing builds:
- plain `docker build` on x86-64 → TARGETARCH=amd64, same output as before
- a builder that sets nothing → falls back to linux/amd64 via ${VAR:-…}
- `docker build` on arm64 → native arm64 image, no patching needed
- `docker buildx build --platform linux/amd64,linux/arm64` → multi-arch image
The builder stage is pinned to --platform=$BUILDPLATFORM so the Go toolchain
keeps running natively and cross-compiles, instead of the whole build stage
being emulated through QEMU (which is very slow for Go builds).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe Docker builder now supports target-platform compilation while preserving Linux amd64 defaults. Drop auto-claim completion uses observed claimed-drop state and excludes inventory campaigns. The stream-source test double now resolves game slugs to fixture names. ChangesCross-platform Docker builds
Drop completion tracking
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Three independent fixes I've been carrying downstream while running this on a
Raspberry Pi. Separate commits, so feel free to take them individually.
1.
fix(test): four selector tests have been failing silentlySince the v2.0 switch to the persisted-hash
GameDirectoryquery, productionpasses the game's URL slug to
GetGameStreamsDropsEnabled, while the testfixtures in
selector_test.goare keyed by display name. The fake sourcereturns no streams,
buildPoolproduces an empty pool, and four tests fail:TestBuildPool_UnrestrictedCampaignTestBuildPool_DirectoryQueriedOncePerGameTestSelect_WantedGamesForcesNonClosestExpiryTestSelect_SkipChannelsExcludesFromPoolgo test ./...on currentmainreproduces this.fakeStreamSourcenow fallsback to matching
SlugFromGameName(fixtureKey)against the requested slug andcounts the call under the fixture key, so the "queried once per game"
assertion keeps working. Fixtures stay readable, no production code touched.
After this commit
go test ./...is green again.2.
fix(drops): campaign marked completed while it still had drops leftautoClaimWith()wrote a campaign tocompleted_campaignsas soon as everydrop it could see was claimed. Twitch sometimes omits
requiredMinutesWatchedfor a campaign's later drops, so after claiming drop3 of 5 the loop concludes "everything claimed", the campaign is filtered out
permanently, and the remaining two drops are abandoned mid-progress. Observed
here on a 5-tier Marble Day campaign.
Completion now additionally requires:
!c.InInventory— while Twitch still lists the campaign as in-progressthere is more to farm. This is the same anchor
MarkCompletedIfFinishedExternallyalready trusts, so both paths now agree.claimedSeen > 0— a campaign whose metadata glitched to "nothingwatchable" can't complete itself without a single observed claim.
No farming loop is introduced by waiting: a genuinely finished campaign that's
still in the inventory is skipped by the selector anyway (no drop reports
IsEarnable) and gets marked on a later cycle once Twitch drops it from thein-progress list.
3.
build: image only ever built for amd64The Dockerfile hard-codes
GOARCH=amd64, so the image can't run on arm64 —Raspberry Pi, Apple Silicon, arm64 VPS. The release workflow already ships a
twitchpoint-linux-arm64binary, so the Docker image was the last place stillpinned. I've been patching this line locally on every update.
GOOS/GOARCHnow come fromTARGETOS/TARGETARCH, which BuildKit setsautomatically, with
${VAR:-…}defaults so nothing changes for existingbuilds:
docker buildon x86-64amd64— unchangedlinux/amd64docker buildon arm64docker buildx build --platform linux/amd64,linux/arm64The builder stage is pinned to
--platform=$BUILDPLATFORMso the Go toolchainkeeps running natively and cross-compiles, rather than the whole build stage
being emulated through QEMU (painfully slow for Go).
Testing
go test ./...— green with commit 1 (red onmainbefore it)go build ./...— cleanwith these three commits, drops and points mining working
Summary by CodeRabbit
Bug Fixes
Tests