Adventofcode Cli Laravel Package

Getting Started

Treat v1.2.2 as a low-risk patch: it fixes duplicate puzzle submission when a puzzle has already been solved. No breaking API or migration is implied by the note, but verify the package’s solved-state storage before relying on the fix.

First steps:

1. Check the package README/config/service provider for how puzzles are fetched, submitted, and marked solved.
2. Publish/configure any package config, especially credentials, endpoints, cache/DB connection, and queue settings.
3. Run the smallest end-to-end flow: solve one puzzle, confirm it is recorded as solved, then attempt the same puzzle again and confirm it is skipped rather than resubmitted.
4. Inspect logs/events around the skip path so “already solved” is visible and distinguishable from submission failure.

First use case: a scheduled or queued job that fetches available puzzles, filters out solved ones, submits only unsolved puzzles, and records success. v1.2.2 should prevent resubmission, but the app should still make the workflow idempotent.

Implementation Patterns

• Filter before dispatch: Query/filter solved puzzles before creating submission jobs. Do not rely solely on the package guard; it is a safety net, not a replacement for app-level selection.
• Idempotent submission job: Give each puzzle submission a stable key (puzzle ID + user/team/context). Check solved state at job start and again immediately before submission where practical.
• Record solved state atomically: After a successful submission, persist the solved marker in the same reliable store the package checks. Use transactions or cache writes with appropriate durability.
• Backfill existing solved puzzles: If the package’s solved-state store is new or incomplete, import historical solved puzzle IDs so v1.2.2 knows what to skip.
• Log skips as normal outcomes: Emit an info-level log/event such as puzzle_skipped_already_solved with puzzle ID and context. Do not treat skips as errors.
• Test the regression directly: Add a feature/integration test that solves a puzzle, runs the submission flow again, and asserts the submission client was called only once.
• Queue and scheduler integration: If using queues, ensure retries do not create duplicate submissions. Combine solved-state checks with unique jobs, locks, or middleware.

Gotchas and Tips

• The fix depends on accurate solved state. If the puzzle was solved before this package tracked it, or the cache/DB entry is missing, v1.2.2 may still resubmit. Backfill and verify storage.
• Race conditions remain possible. Two workers can both see “unsolved” before either writes the solved marker. Use locks or atomic “claim then submit” patterns for high-concurrency queues.
• Cache quirks can bypass the guard. Check TTLs, cache prefixes, store drivers, and whether solved markers are written to the same connection/environment the checker reads.
• Debug by tracing one puzzle ID. Log the puzzle ID, solved-check result, submission decision, and post-submit write. Then replay the same puzzle twice.
• Do not swallow skip reasons. Distinguish “already solved,” “submission succeeded,” “submission failed,” and “duplicate suppressed by lock.” This makes production debugging much easier.
• Review extension points before custom code. Prefer the package’s solved-state repository/checker, events, or submission wrapper if available; otherwise wrap the submission client so duplicate checks are centralized.
• Pin and monitor. This is a patch fix, but keep the version pinned and review future changelogs for changes to solved-state semantics or submission behavior.