Findings

P1 — Panic on missing file in upload handler
Location: src/handlers/upload.rs:114

Issue: The code calls .unwrap() on Path::new(&filename).canonicalize(). canonicalize() returns an Err when the target file does not exist (or is otherwise inaccessible), and the unwrap() will panic in that case.

Impact: A missing file (e.g., client references a filename that was never uploaded, was deleted, or contains a path that doesn't resolve) crashes the request-handling thread. Depending on the async runtime/executor configuration, this can:

• Terminate only the single request (best case, if caught by a panic boundary), or
• Poison shared state / take down the worker if no panic isolation is in place.

Either way, it's an unhandled-error-as-crash pattern that should never be reachable from untrusted/external input.

Suggested fix: Replace .unwrap() with proper error propagation, e.g.:

let canonical = Path::new(&filename)
    .canonicalize()
    .map_err(|e| AppError::BadRequest(
        format!("invalid file path: {e}")
    ))?;

Return a 400/404 to the client instead of panicking. Add a test case covering a non-existent filename.

P2 — New PgPool created per request instead of reusing shared pool
Location: src/db/pool.rs:29

Issue: A new PgPool is instantiated on every request rather than reusing a single, shared pool constructed once at startup.

Impact: Each PgPool::new(...) (or equivalent) opens its own set of connections to Postgres. Under load this:

• Rapidly exhausts available Postgres connections (hits max_connections on the DB server), causing connection errors for concurrent requests.
• Adds significant per-request latency from repeated connection/handshake overhead.
• Defeats the purpose of connection pooling entirely, since pools are not meant to be short-lived.

This is a correctness/scalability issue that will manifest as request failures and degraded throughput as concurrency increases, and could also affect other services sharing the same Postgres instance.

Suggested fix: Construct the PgPool once (e.g., in application startup / main.rs or a lazily-initialized static/OnceCell), then inject or pass a reference/clone (pools are typically Arc-backed and cheaply cloneable) into request handlers via app state (e.g., web::Data<PgPool> in Actix, State<PgPool> in Axum, etc.). Verify no other call sites have the same per-request instantiation pattern.

P1 — src/handlers/upload.rs:114: Path::new(&filename).canonicalize().unwrap() panics if the file doesn't exist, crashing the request thread. Fix: replace .unwrap() with proper error handling (e.g. .map_err(...)? returning a 4xx/5xx response) instead of panicking.

P2 — src/db/pool.rs:29: creates a new PgPool per request instead of reusing a shared pool, exhausting DB connections under load. Fix: construct the PgPool once at startup (e.g. in app state) and pass a reference/handle into each request instead of instantiating per-request.

Subject: inventory-sync — Status Update

Hi [Manager],

Quick update on inventory-sync:

• Kafka consumer rewrite is deployed to canary.
• Performance: canary pods show p99 latency at 340ms, well within our 500ms SLO.
• Issue: readiness probe on pod inventory-sync-7f9d8 is failing with connection refused on port 9090.
• Rollout status: paused before proceeding to the remaining 90% of pods, pending investigation of the probe failure.

Will update once we've root-caused the connection issue and are ready to resume the rollout.

Thanks,
[Your name]

Status: inventory-sync

• Kafka consumer rewrite deployed to canary.
• Canary p99 latency: 340ms (within 500ms SLO).
• Blocker: readiness probe failing on pod inventory-sync-7f9d8 — connection refused on port 9090.
• Rollout to remaining 90% paused pending fix.

Diagnosis

Root cause: A context deadline budget mismatch — the 200ms timeout attached to the context in CreateOrderHandler is smaller than the actual latency required by the downstream work performed inside pricing.Calculate.

Specifically:

• CreateOrderHandler creates a context with a 200ms deadline (likely via context.WithTimeout(ctx, 200*time.Millisecond)) and passes that same context through the entire call chain: inventory.Reserve() → pricing.Calculate().
• inventory.Reserve() consumes ~40ms, leaving only ~160ms of budget remaining on that context by the time pricing.Calculate() is invoked.
• pricing.Calculate() internally calls a currency conversion API that averages ~350ms.
• Since the context's deadline is shared and cumulative across both calls (not reset or given its own independent timeout for the pricing step), the 200ms deadline is exceeded roughly 150–190ms into the currency conversion call.
• The context's internal timer fires, cancels the context, and the HTTP client (or whatever transport pricing.Calculate uses to call the currency conversion API) returns context deadline exceeded because the request's ctx.Done() channel closed before the response arrived.

Exact point of failure: Inside pricing.Calculate(), specifically at the call site where it invokes the currency conversion API using the inherited context (e.g., the client.Do(req.WithContext(ctx)) or equivalent HTTP call). The deadline check that trips is the ctx.Err() / <-ctx.Done() evaluation performed by the HTTP client's transport layer during that outbound call, not any logic within pricing.Calculate itself.

Why inventory.Reserve() is unaffected: It completes in ~40ms, well under the 200ms budget, so it returns before the shared context's deadline is reached — the failure only manifests once the remaining budget (200ms − reserve time) is insufficient for the currency conversion API's ~350ms average latency.

Underlying issue in one sentence: A single 200ms context deadline is being shared across two sequential operations (inventory.Reserve + pricing.Calculate's external currency API call) whose combined/individual latency requirements exceed that budget, and there is no per-stage timeout or budget allocation to account for pricing.Calculate's dependency on a ~350ms external call.

Root cause: budget mismatch. CreateOrderHandler allocates a single 200ms timeout to the whole request context, but by the time inventory.Reserve() (~40ms) finishes, pricing.Calculate() has ~160ms left — less than the currency conversion API's ~350ms average latency. The timeout is too small for the slowest downstream call it must cover, so every call to the currency conversion API blows the deadline.

Exact failure location: inside pricing.Calculate(), at the call to the currency conversion API (the ctx.Done()/deadline check triggered during or after that HTTP call). inventory.Reserve() is not the problem — it completes well inside the budget.

Not yet diagnosed (would need code to confirm): whether pricing.Calculate derives a fresh sub-context/timeout for the currency API call or just inherits the parent's remaining deadline, and whether the 200ms figure was sized only for inventory.Reserve()'s SLA without accounting for pricing.Calculate()'s external dependency.