Back to Spring roadmap

Applied skills · retrieval review

Can you diagnose and extend TaskFlow deliberately?

Make the call before seeing the explanation: testing, observability, ownership, authentication, and change design.

Learning goal

Attempt first

  1. A service rejects duplicate task titles. What collaborator would you stub, what behavior would you assert, and which interaction is not worth verifying?
  2. A controller accepts invalid JSON and returns 500. Choose a smallest useful test slice and predict the response contract it should assert.
  3. A production request is slow but succeeds. Choose two log fields and one level that help correlate the request without turning logs into a data leak.
  4. A user can read another owner’s task by changing an ID in the URL. Identify the missing check and where it belongs in the request path.
  5. A bearer token is valid but the endpoint still returns 403. What claims, filter behavior, and authority mapping would you inspect?
  6. Design a TaskFlow “move task” change that changes owner and project. Which invariants belong in the service, and what should happen if the second update fails?

Completion evidence

Choose one TaskFlow change above. Write its acceptance checks, implement or sketch its service boundary, and list the test and log evidence you would use to verify it.

Current status: Not started

Open answer structures after your attempt

Start each answer with the observable behavior, then name the narrowest boundary that proves it. Use a mock for isolated service policy and a slice for web binding or validation. Log identifiers and elapsed time, not credentials. Enforce ownership in the service using authenticated identity, and make related state changes one unit of work. Security diagnoses should distinguish token validation from authority conversion.