[Invoices]: Peppol hardening follow-ups (Qonto settings contract, log redaction, audit-tool gap, scheduler cron)

[nielsdrost7]

Summary

A checklist of smaller hardening gaps found while auditing feature/126-implement-peppol, each individually small but worth tracking rather than losing.

1. Qonto's settings() declares an optional key as mandatory

Modules/Invoices/Peppol/Clients/Qonto/QontoClient::settings() returns ['access_token', 'staging_token']. QontoProvider doesn't override authenticate(), so it falls through to BaseProvider::authenticate() (Modules/Invoices/Peppol/Providers/BaseProvider.php:106-117), which loops over every key settings() returns and fails if any is empty — treating both as equally mandatory. But staging_token is used only conditionally (QontoClient::getAuthenticationHeaders(): if ($this->stagingToken) { ... }) — it's an optional sandbox header, not a real auth requirement. Net effect: a fully and correctly configured production Qonto integration (real access_token, no staging_token) would report authenticate() === false. Compare with EInvoiceBeProvider (['api_key']) and StorecoveProvider (['api_key', 'legal_entity_id']), where every listed key genuinely is unconditionally required — Qonto is the one sibling that drifted from that pattern. Currently inert (nothing calls ->authenticate() on any provider yet outside the class hierarchy itself), but part of the public ProviderInterface contract, so it's a landmine for whenever something starts calling it.

Fix shape: decide how ProviderInterface should express "required vs. optional" settings (e.g. a second optionalSettings() method, or a keyed array with per-key required flags) and update BaseProvider::authenticate()'s default accordingly.

2. Request/response logger's secret redaction has a gap

The request/response logger's secret redaction misses the request payload and response body — dormant today (the feature flag is off by default, never enabled in production code), but would leak plaintext client_secret/access_token the moment it's switched on for debugging.

Fix shape: extend the redaction to cover the full request payload and response body, not just whatever fields it currently covers.

3. FormDbConstraintAuditTest has a blind spot: it can't see a NOT-NULL column missing from a form entirely

Modules/Core/Tests/Feature/FormDbConstraintAuditTest.php only iterates fields that are present in the resolved form schema and checks whether their rules are strict enough — it never walks the DB schema the other way to ask "is every NOT-NULL/no-default column represented by some form field at all?" This is exactly why it stayed green despite merchant_clients.client_id being NOT NULL with no form field (fixed in the PR this issue was filed from, but the audit tool itself still can't catch the next occurrence of this bug class).

Fix shape: extend auditResource() with a reverse pass — for each NOT-NULL, no-default, non-autoincrement column not in {id, created_at, updated_at, deleted_at}, assert it has a corresponding entry in the form's fields, subject to the same FormDbGapKnownExceptions::KNOWN_GAPS allowlist.

4. No cron/scheduler runner exists in the dev or deploy stack

bootstrap/app.php now has a withSchedule() callback registering peppol:poll-status (every 15 min) and peppol:retry-failed (every minute) — but nothing in the project's docker stack (ivpldock-workspace-1 and friends) or deploy configuration actually runs php artisan schedule:run on a timer. Confirmed: no cron container, no supervisor entry, no /etc/cron.d/* beyond the stock PHP session-cleanup job. Laravel's scheduler is inert without something invoking schedule:run every minute.

Fix shape: add a cron entry or supervisor process to the deploy/dev stack that runs php artisan schedule:run every minute (commonly a dedicated lightweight scheduler container, or a cron line in the existing php-fpm/workspace image).

Source

Found by mind-the-gap and release-resilience audits of feature/126-implement-peppol vs develop on 2026-09-12.

[nielsdrost7]

Addendum: found while building a real end-to-end test for #770

Modules\Clients\Models\Relation (the customer model) has no country_code column at all — confirmed via Schema::getColumnListing('relations'). Yet BaseFormatHandler::supports()/getEndpointScheme() and PeppolBisHandler::transform() all read $invoice->customer?->country_code, which is always null (Eloquent returns null for an attribute that isn't a real column rather than erroring on read — it only surfaces when something tries to write it, e.g. a factory ::create(['country_code' => ...]) throws Unknown column).

Effect: every country-based Peppol decision — "is this format mandatory for the customer's country," "which endpoint scheme applies" — silently falls through to the default case for every customer, regardless of their actual country. Not a crash, just silently wrong format/scheme selection.

Also found in the same investigation, and already fixed directly (both were blocking a real send from ever completing, found while getting a genuine end-to-end SendInvoiceToPeppolJob test to pass):

• Relation had no hasPeppolIdValidated() method at all — SendInvoiceToPeppolJob::validateInvoice() called it unconditionally, so every send fataled at the first validation check. Added the method + a proper PeppolValidationStatus enum cast (peppol_validation_status had no cast either).
• SendInvoiceToPeppolJob::validateInvoice() checked $invoice->number, which doesn't exist — the real column is invoice_number. Every send fataled here too, right after the above.
• SendInvoiceToPeppolJob::calculateIdempotencyKey() read $invoice->updated_at->timestamp — Invoice::$timestamps is false and the invoices table has no timestamp columns at all, so this was always a null-property-access fatal. Fixed by dropping that key ingredient (see the comment left in the method — the resulting idempotency key is identity-only, no schema change made).
• PeppolTransmission::setProviderResponse() never set company_id explicitly, relying on BelongsToCompany's auto-injection — which only works with a Filament tenant or session in scope, neither of which exists in a real queued-job execution context. Every provider response ever stored via a real queue worker would have hit a NOT NULL violation. Fixed by setting company_id explicitly, mirroring how PeppolTransmission::create() itself already does it.

None of these four were reachable/visible until an actual end-to-end test was written and run — this file had zero test coverage before now (see #770/#772), so nobody had ever executed this job even once.

Recommended fix for the country_code gap: decide where country should live for a Relation — most likely on the primary/billing Address (which already exists as a MorphOne relation) rather than a new column directly on relations, then update BaseFormatHandler/PeppolBisHandler to read from there.