eefc0457be
All checks were successful
build-and-release / build (catering-services) (push) Successful in 1m31s
build-and-release / build (cron) (push) Successful in 1m54s
build-and-release / build (companies) (push) Successful in 2m7s
build-and-release / build (customers) (push) Successful in 2m53s
build-and-release / build (fitness-trainers) (push) Successful in 1m29s
build-and-release / build (developers) (push) Successful in 1m43s
build-and-release / build (gateway) (push) Successful in 1m35s
build-and-release / build (employees) (push) Successful in 2m15s
build-and-release / build (jobs) (push) Successful in 1m10s
build-and-release / build (graphic-designers) (push) Successful in 2m9s
build-and-release / build (makeup-artists) (push) Successful in 1m35s
build-and-release / build (photographers) (push) Successful in 1m44s
build-and-release / build (job-seekers) (push) Successful in 3m8s
build-and-release / build (payments) (push) Successful in 2m45s
build-and-release / build (social-media-managers) (push) Successful in 2m35s
backend-integration-tests / ai-credits (push) Successful in 50s
build-and-release / build (tutors) (push) Successful in 3m10s
build-and-release / build (ugc-content-creators) (push) Successful in 2m49s
build-and-release / build (video-editors) (push) Successful in 2m48s
build-and-release / build (users) (push) Successful in 4m38s
The fixed UUID (33333333-...) meant every re-run against the same persistent test database reused the same wallet - any earlier partial run that panicked before its own capture/release step left reserved_credits permanently stuck above zero, so this run's fresh reserve (expected to bring it to exactly 4) actually reads 8, 12, etc. depending on how many times the suite had previously failed midway. Matches ai_credits.rs's make_user() pattern (Uuid::new_v4()) instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| migrations | ||
| migrations_new | ||
| src | ||
| tests | ||
| Cargo.toml | ||