92ce2d2a86
All checks were successful
build-and-release / build (catering-services) (push) Successful in 15s
build-and-release / build (cron) (push) Successful in 13s
build-and-release / build (developers) (push) Successful in 10s
build-and-release / build (employees) (push) Successful in 8s
build-and-release / build (fitness-trainers) (push) Successful in 5s
build-and-release / build (gateway) (push) Successful in 5s
build-and-release / build (graphic-designers) (push) Successful in 5s
build-and-release / build (job-seekers) (push) Successful in 5s
build-and-release / build (jobs) (push) Successful in 6s
build-and-release / build (payments) (push) Successful in 4s
build-and-release / build (makeup-artists) (push) Successful in 6s
build-and-release / build (photographers) (push) Successful in 5s
build-and-release / build (social-media-managers) (push) Successful in 6s
build-and-release / build (tutors) (push) Successful in 6s
build-and-release / build (ugc-content-creators) (push) Successful in 6s
build-and-release / build (video-editors) (push) Successful in 6s
build-and-release / build (companies) (push) Successful in 2m9s
build-and-release / build (customers) (push) Successful in 2m47s
build-and-release / build (users) (push) Successful in 3m16s
Found while investigating "notifications/emails not working on approve or job posting": 1. Real bug: apps/companies/src/handlers/mod.rs::view_contact (company viewing an applicant's contact info) inserted into notifications using column name `notification_type`, which has never existed — the column is `type`. This INSERT has been failing outright every time a company views a contact. 2. Root cause for approvals specifically: verifications/approval_requests never existed until earlier this session (see 20260718200000_create_verifications_and_approvals) — every admin approve/reject action was failing at the DB layer before it ever reached the notification/email code, so nothing in this area could have worked regardless of the email/notification logic itself. 3. Observability gap: every `state.mail.send_*_email(...)` call site silently discarded its Result (`let _ = ...`), so if the SMTP/ Zeptomail provider is unconfigured (crates/email::Mailer already logs a clear warning at startup for that, but callers gave no per-send signal) or a send fails for any other reason, there was no way to see it happen. Added `tracing::error!` logging on failure for every job/approval-related email: job submitted, job approved, job rejected, requirement approved, profile approval approved/rejected, requirement submitted. Doesn't change delivery — if the environment has no EMAIL_PROVIDER/SMTP_*/ZEPTOMAIL_* configured, sends still fail, but that failure is now visible in logs instead of silent. In-app notifications for approvals were already schema-correct (job/profile/requirement approve+reject all insert into notifications with the right columns) — the two real defects were #1 and #2 above. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| Dockerfile | ||