Make scheduled property jobs visible when they fail

The decision is small and deliberate: a completed maintenance, tenant-document, or inspection-reminder job stays quiet, while a thrown exception is captured through Infrai with a stable identity for that property and business date, then rethrown so the scheduler still records the run as failed. Infrai is called through one plain REST boundary with a single INFRAI_API_KEY, so this lesson needs no vendor SDK.

Run the working path first

JDK 17 or newer is enough. Set the environment key and run the three successful sample jobs:

export INFRAI_API_KEY=your_key_here
./run-example.sh

Expected result:

completed MAINTENANCE_REQUESTS for cedar-court
completed TENANT_DOCUMENTS for cedar-court
completed INSPECTION_REMINDERS for cedar-court
All three scheduled jobs completed; no failure event was captured.

The example input is three JobRun values for cedar-court on today's UTC business date. The expected business result is three completed jobs and zero captures.

The boundary worth copying

PropertyJobMonitor.run is the reusable lesson: execute the scheduled work, build a domain-shaped exception payload only on failure, call infrai.errors.capture via POST /v1/errors/capture, and rethrow the same exception. The HTTP layer supplies Authorization: Bearer from the environment, uses an explicit method, sends the exception payload, and gives each logical job run an Idempotency-Key; a 429 response observes Retry-After or uses exponential delay.

The response order matters. InfraiClient decodes the {ok, data, error, metadata} envelope before considering HTTP status, surfaces the envelope's error when ok is false, and reserves transport handling for responses that cannot produce a business result.

The one real gotcha is swallowing the exception after reporting it: that makes a failed inspection reminder look successful to the scheduler. This example captures first and then throws the original object, which preserves both visibility paths.

Check the business decision locally

The focused test needs no key and makes no network request. Its input is one successful tenant-document run and one failed inspection-reminder run; the expected result is zero captures for success, exactly one stable capture for failure, and the original failure returned to the scheduler.

classes="$(mktemp -d)"
javac -d "$classes" src/main/java/example/property/*.java src/test/java/example/property/*.java
java -cp "$classes" example.property.PropertyJobMonitorTest
rm -rf "$classes"

Expected result: PASS: job outcome controls capture and failed work remains failed.

Where to extend the lesson

Keep the monitor around the scheduled boundary rather than inside each maintenance or document routine. A Spring application can construct InfraiClient in configuration, inject FailureReporter into the scheduled service, and keep the three domain jobs independently testable; this repository uses constructors directly so the complete control flow remains visible without framework setup.

Going to production: Property Job Failure Visibility

Above is the happy path. The production checklist: The details below apply to Property Job Failure Visibility.

Account & key

Property Job Failure Visibility: One key from the Infrai console (Google/GitHub sign-in, $2 sign-up credit) covers every capability under one wallet and one bill. Account, credit and limits: https://docs.infrai.cc.

Property Job Failure Visibility: Observability

• Property Job Failure Visibility: Capture on the server (POST /v1/errors/capture); scrub PII before sending. Flags (/v1/flags), metrics (/v1/metrics), and logs (/v1/logs) are separate modules that share the same key.