cd695514fe
All checks were successful
build-and-release / build (developers) (push) Successful in 1m27s
build-and-release / build (employees) (push) Successful in 1m52s
build-and-release / build (customers) (push) Successful in 1m56s
build-and-release / build (cron) (push) Successful in 2m16s
build-and-release / build (companies) (push) Successful in 2m21s
build-and-release / build (catering-services) (push) Successful in 2m29s
build-and-release / build (gateway) (push) Successful in 39s
build-and-release / build (fitness-trainers) (push) Successful in 2m0s
build-and-release / build (graphic-designers) (push) Successful in 1m52s
build-and-release / build (jobs) (push) Successful in 1m34s
build-and-release / build (job-seekers) (push) Successful in 2m4s
build-and-release / build (photographers) (push) Successful in 1m35s
build-and-release / build (makeup-artists) (push) Successful in 2m41s
build-and-release / build (payments) (push) Successful in 3m15s
build-and-release / build (tutors) (push) Successful in 2m16s
build-and-release / build (social-media-managers) (push) Successful in 2m33s
build-and-release / build (ugc-content-creators) (push) Successful in 2m47s
build-and-release / build (video-editors) (push) Successful in 2m32s
build-and-release / build (users) (push) Successful in 4m11s
Document upload endpoints (job_seekers, customers, companies, and the profession_shared crate used by 10 profession apps) returned a generic "File upload failed" 500 on any storage error, hiding the actual cause from both the API response and (for job_seekers/companies) the server logs, which only printed anyhow's outer context via Display instead of the full error chain via Debug. Also add an explicit DefaultBodyLimit(11MB) to every affected app's router — none had one, so axum's implicit 2MB default could silently reject uploads under the UI's advertised 10MB cap. |
||
|---|---|---|
| .. | ||
| admin.rs | ||
| handlers.rs | ||
| main.rs | ||