WEB / WEB-16.03

Routing, middleware, and handlers

Trace method/path routing, local middleware continuation, and handler response ownership separately.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Ordered GET

Public GET ready
The client selects GET /notes?view=plain with no body and no server context yet.
Client / Duru
GET ready
HTTP server
No request
Router / middleware
No context
Handler / result
No result
Request arrival
The HTTP request arrives at the server, making method GET and target available for context.
Client / Duru
Waiting response
HTTP server
GET target received
Router / middleware
Context pending
Handler / result
No result
Local request ref
Middleware creates local read-a correlation; its next continuation is not a network message.
Client / Duru
Waiting response
HTTP server
Request context active
Router / middleware
request-ref stage complete
Handler / result
No result
Local route select
The router separates pathname /notes from query view=plain and selects GET noteRead.
Client / Duru
Waiting response
HTTP server
Request context active
Router / middleware
route selected noteRead
Handler / result
Handler pending
Local presentation
Presentation middleware prepares harmless view state, completing handler prerequisites.
Client / Duru
Waiting response
HTTP server
Request context active
Router / middleware
presentation ready; ordered trace
Handler / result
Handler ready
Local handler
noteRead produces Routed note and response200 with no storage write or commit in this fixture.
Client / Duru
Waiting response
HTTP server
Response200 prepared
Router / middleware
Cycle terminal
Handler / result
Routed note; 11 bytes
Local response end
The terminal owner calls end once; OS handoff does not yet change client-received state.
Client / Duru
Waiting response
HTTP server
end once; finish OS handoff
Router / middleware
Cycle terminal
Handler / result
No persistence operation
Response arrival
Valid response200/content reaches the client and is observed as a transport result.
Client / Duru
200 Routed note received
HTTP server
Exchange complete
Router / middleware
Cycle terminal
Handler / result
No commit claim

Method mismatch

Public input ready
The client selects harmless POST /notes with no application mutation or identity.
Client / Duru
Request ready
HTTP server
No request
Router / middleware
No context
Handler / result
No result
Request arrival
The HTTP request arrives at the server for local route-context processing.
Client / Duru
Waiting response
HTTP server
POST /notes received
Router / middleware
Context pending
Handler / result
No result
Local request ref
Middleware establishes harmless correlation context without invoking a handler.
Client / Duru
Waiting response
HTTP server
Request context active
Router / middleware
request-ref complete
Handler / result
Handler not invoked
Local selection
The selected manual contract chooses 405: GET route exists but selected method does not; normal handler processing stops.
Client / Duru
Waiting response
HTTP server
Response405 selected
Router / middleware
GET route exists but selected method does not
Handler / result
Handler not invoked
Local terminal
The fallback prepares one terminal response with status 405, Allow: GET and the Method not allowed body. Handler and presentation stages do not run; this is the example’s manual method policy.
Client / Duru
Waiting response
HTTP server
405 ready; end once
Router / middleware
Cycle terminal
Handler / result
Handler not invoked
Response arrival
Normal valid HTTP 405 and harmless text reach the client rather than a network error.
Client / Duru
405 Method not allowed received
HTTP server
Exchange complete
Router / middleware
Cycle terminal
Handler / result
Handler not invoked

Route absent

Public input ready
The client selects harmless GET /absent with no application mutation or identity.
Client / Duru
Request ready
HTTP server
No request
Router / middleware
No context
Handler / result
No result
Request arrival
The HTTP request arrives at the server for local route-context processing.
Client / Duru
Waiting response
HTTP server
GET /absent received
Router / middleware
Context pending
Handler / result
No result
Local request ref
Middleware establishes harmless correlation context without invoking a handler.
Client / Duru
Waiting response
HTTP server
Request context active
Router / middleware
request-ref complete
Handler / result
Handler not invoked
Local selection
The selected manual contract chooses 404: No selected route exists; normal handler processing stops.
Client / Duru
Waiting response
HTTP server
Response404 selected
Router / middleware
No selected route exists
Handler / result
Handler not invoked
Local terminal
The fallback prepares one terminal 404/Route not found response and blocks second completion.
Client / Duru
Waiting response
HTTP server
404 ready; end once
Router / middleware
Cycle terminal
Handler / result
Handler not invoked
Response arrival
Normal valid HTTP 404 and harmless text reach the client rather than a network error.
Client / Duru
404 Route not found received
HTTP server
Exchange complete
Router / middleware
Cycle terminal
Handler / result
Handler not invoked

Handler error

Fail-read ready
The client selects harmless GET /notes/fail as a fixture failure with no request body.
Client / Duru
GET fail ready
HTTP server
No request
Router / middleware
No context
Handler / result
No result
Request arrival
The HTTP GET arrives at the server with request context ready for the local pipeline.
Client / Duru
Waiting response
HTTP server
GET fail received
Router / middleware
Context pending
Handler / result
No result
Local prerequisites
Request-ref, route, and presentation stages are built in order for the selected failure handler.
Client / Duru
Waiting response
HTTP server
Headers not sent
Router / middleware
Prerequisites ready
Handler / result
Failure handler selected
Local handler error
The handler raises a supplied harmless error before headers, with no response/content sent yet.
Client / Duru
Waiting response
HTTP server
Headers not sent
Router / middleware
Error continuation
Handler / result
Pre-header fixture error
Local error map
The selected mapper chooses controlled status500/Service unavailable without a stack or secret body.
Client / Duru
Waiting response
HTTP server
Response500 ready
Router / middleware
error-map terminal owner
Handler / result
No persistence operation
Local terminal
One terminal response is ended; this branch does not model post-header stream recovery.
Client / Duru
Waiting response
HTTP server
end once; finish OS handoff
Router / middleware
Cycle terminal
Handler / result
No commit claim
Response arrival
Valid controlled 500 content reaches the client, keeping status and completion distinct.
Client / Duru
500 Service unavailable received
HTTP server
Exchange complete
Router / middleware
Cycle terminal
Handler / result
No commit claim

ACTORS · STATE · DATA FLOW

A framework organizes execution

A web framework organizes request/response handling above a runtime using abstractions such as routers, middleware composition, handlers/controllers, and error paths. Its name does not itself define HTTP parsing or JavaScript execution. The Express guides describe routing and middleware as a sequence of function calls in a request-response cycle. This small manual Node pipeline demonstrates that role distinction without implementing every Express matching or error rule.

The router chooses which handler is bound to an HTTP method and route path. In GET /notes?view=plain, pathname /notes and query view=plain are separate inputs. Express route paths exclude query strings; matching, normalization, and version rules vary in other frameworks. A URL path is not object permission: matching only chooses a processing target.

The selected table contains only GET /notes and GET /notes/fail. A different method at /notes receives 405 and Allow: GET under this manual contract; other frameworks need not select that status automatically. /absent produces a 404 route outcome. Both branches terminate before invoking the handler, based on the route table and method policy.

Middleware produces state or ends the cycle

Middleware can read/change request context, prepare a response, raise an error, or pass control through a continuation. Express normal middleware that does not end the cycle must call next(); doing neither can leave a hanging request. The presence of middleware does not prove it ran for a request in the correct order. Mount/path, method, and earlier cycle completion affect execution.

The Atlas pipeline first creates a harmless requestRef, routes method/path, prepares presentation context for the selected route, and invokes the handler. The handler consumes requestRef and normalized view state. Ordering establishes these prerequisites. Local next and handler calls are not HTTP packets; they are control flow within one application process. The scene separates remote client/server transfer from local stages accordingly.

Once the handler ends the cycle with a response, subsequent normal handlers do not run. Absent routes and method mismatches use fallback responses. Selected /notes/fail raises a harmless fixture error before headers, and a local mapper chooses controlled 500 Service unavailable text. This does not claim every Node/Express async exception is automatically caught. Define error contracts, framework versions, and Promise/stream lifecycles separately.

One response owner and bounded completion

A handler/controller connects input to application logic and maps a domain result/representation to an HTTP response. The controller name guarantees no database write or transaction. This public handler only reads Routed note, with no persistence operation. For stateful actions, commit, response preparation, and client observation are different events requiring the storage contract in WEB-18.

Node headersSent means headers were sent; writableEnded means end() was called; writableFinished describes flushing to the underlying system. ServerResponse finish means its final segment was handed to the OS for transmission, not proof of client receipt/consumption or business commit. The native fixture separately observes final status and client content with valid Content-Length. Routed note is 11 UTF-8 bytes; string character count is not a general byte-length calculation.

The application should own one terminal decision. Sending a second normal response with a different status/content after headers have started is outside a valid response lifecycle; connection handling depends on stream/error outcomes. This fixture stops a second logical completion before transmission with a terminal guard, without malformed messages. Post-header abort or persistence failure need not be handled by the same pre-header mapper.

Read every scenario without motion

Method mismatch

Method and pathname were selected
MethodMismatch is prepared for POST /notes. A path appearing in routeTable does not mean the method gate also passed.
Request/completion context
POST /notes
Selection/runtime boundary
No route selection
Handler/business outcome
Handler not called
The route-table method was read
RouteTable maps GET /notes to noteRead. This finite public-route contract does not dispatch POST to the handler.
Request/completion context
POST /notes
Selection/runtime boundary
Expected method=GET
Handler/business outcome
Handler not called
The method gate stopped before the handler
handlerInvoked=false and status=405 are supplied. Allow=GET describes the method supported by this route, not object permission.
Request/completion context
Method mismatch
Selection/runtime boundary
405; Allow=GET
Handler/business outcome
Handler invoked=false
Presentation query was not treated as permission
In the normal GET target, query view=plain is separate from pathname. This harmless presentation choice changes neither the method nor authentication gate.
Request/completion context
Method mismatch
Selection/runtime boundary
Query ≠ method/permission
Handler/business outcome
Handler invoked=false
The response owner remained explicit
The Method not allowed body belongs to route selection. RouteAbsent 404 and methodMismatch 405 have different causes; neither invokes the handler.
Request/completion context
Method not allowed
Selection/runtime boundary
Selection-level response
Handler/business outcome
No handler grant inferred
The routing conclusion was not expanded into authorization
This case explains only method/path dispatch. A middleware appearing in a list does not prove pre-handler access checks on every protected route.
Request/completion context
Known: method mismatch
Selection/runtime boundary
Known: no handler dispatch
Handler/business outcome
Authorization requires separate evidence

Finish boundary

Response-completion metadata was selected
Completion has endCalls=1 and secondLogicalCompletionBlocked=true. Terminal-response state is not the same field as business commit or client receipt.
Request/completion context
Completion record
Selection/runtime boundary
Transport state not read
Handler/business outcome
Business/receipt unknown
Sent and ended state were read
headersSentAfterTerminal and writableEndedAfterTerminal are true. These local API states are read separately from the second logical-completion guard.
Request/completion context
Terminal response
Selection/runtime boundary
Headers sent; writable ended
Handler/business outcome
Business/receipt unknown
The finish boundary was interpreted correctly
finishMeansOSHandOff=true and finishProvesClientReceived=false. Server handoff to the OS does not prove that a remote browser read the full body.
Request/completion context
Terminal response
Selection/runtime boundary
OS handoff only
Handler/business outcome
Client receipt not proven
Absence of persistence evidence was preserved
persistenceOperation=null and commitProven=false. Preparing a read response establishes neither storage mutation nor a committed transaction.
Request/completion context
Read completion
Selection/runtime boundary
No persistence operation
Handler/business outcome
Commit not proven
An unsupported success claim was withheld
Adding committed=true to a finish observation invents business state. Client-success indicators and storage success need their own source results.
Request/completion context
Known: terminal response state
Selection/runtime boundary
Transport/persistence separate
Handler/business outcome
No inferred commit/receipt
The terminal guard retained its scope
A second logical completion is blocked without producing an actual malformed response. This local guard alone guarantees neither network delivery nor all error handling.
Request/completion context
One logical completion
Selection/runtime boundary
Second completion blocked
Handler/business outcome
UNKNOWN: client receipt

ASSUMPTION · BOUNDARY · CONTROL

Do not equate route matching with permission

Method/path matching chooses the code reached, without automatically validating user, tenant, or object authorization. Middleware presence does not prove a check ran on the route before the handler. The broken assumption is treating routing/presentation context as authoritative access control. Personalized operations can be affected according to the application control chain; this public reader accepts no identity.

Wrong ordering can make a handler use missing context or let an early terminal response skip later observation stages. Keep dependencies and next/terminal ownership explicit. The public-note expected trace is request-ref, route, presentation, handler. A normal trace mismatch supports debugging, not an automatic policy-bypass or compromise judgment.

Overtrusting completion

Interpreting server finish as client action success or a committed transaction exceeds observation boundaries. For a normal read, the client can separately confirm content; persistence needs storage results. The condition is collapsing transport/local lifecycle and business state into one success field. Impact can include stale UI, wrong confirmations, or confused error handling depending on operation.

Mapping a pre-header handler error to controlled 500 is a failure boundary. Applying the same response after headers risks duplicate responses or truncated transfers. Track terminal ownership, sent/ended/finished state, and exception phase, blocking second completion before transmission. The presence of this control is separate from observing 500, which alone proves neither a leak nor an attack.

Read every scenario without motion

Pre-header error

Handler-error evidence was selected
Review examines handlerError for GET /notes/fail. beforeHeaders=true is the defining condition for producing the error response.
Route/error observation
GET /notes/fail
Stage/owner review
Stage trace not read
Outcome evidence scope
Final outcome not read
The expected-stage trace was compared
The trace contains request-ref, route, presentation, handler and error-map in order. Error-map is the terminal owner after the handler, not the same handler-success outcome.
Route/error observation
GET /notes/fail
Stage/owner review
Handler → error-map
Outcome evidence scope
Final outcome not read
Pre-header error mapping was read
status=500 and body=Service unavailable are supplied. This controlled mapping is not automatically applied to streaming errors after headers start.
Route/error observation
Known: beforeHeaders=true
Stage/owner review
Terminal owner=error-map
Outcome evidence scope
500 Service unavailable
Error status was not treated as attack evidence
500 can represent a server-side failure; this record does not establish a data leak or malicious actor. Internal cause and external response are different observation fields.
Route/error observation
Known: controlled error mapping
Stage/owner review
Internal cause not established
Outcome evidence scope
No actor attribution
Client-delivery evidence stayed separate
Terminal status/body is a server outcome. Server finish, client receipt and DOM feedback need separate observations; the missing fields are not filled in here.
Route/error observation
Declared 500 response
Stage/owner review
Before-header scope retained
Outcome evidence scope
UNKNOWN: actual client receipt
The error-boundary conclusion was closed
This row shows a handler error reaching error-map under the before-headers condition. Post-header termination and transaction rollback lie outside this fixture.
Route/error observation
Known: handler/error-map order
Stage/owner review
Known: controlled response
Outcome evidence scope
Other error phases unknown

Trace gap

The normal-trace review scope was narrowed
This branch reviews the request-ref and route prefix of the normal trace. Missing presentation and handler observations are marked as evidence gaps.
Route/error observation
Normal trace prefix
Stage/owner review
Later-stage evidence missing
Outcome evidence scope
Handler outcome unknown
Route-selection evidence was read
GET /notes?view=plain selects pathname=/notes. Naming handler noteRead does not establish its execution in this partial observation.
Route/error observation
GET pathname=/notes
Stage/owner review
Selected handler=noteRead
Outcome evidence scope
Handler execution unknown
Missing dependency state was preserved
The handler is expected to follow prepared presentation state. A missing presentation record establishes neither that the stage was skipped nor that it completed.
Route/error observation
Selected normal route
Stage/owner review
Presentation evidence missing
Outcome evidence scope
UNKNOWN: stage progression
A missing log was not treated as bypass evidence
A middleware list or missing event is not a protected-route permission outcome. The public-read fixture accepts no authentication; no grant is invented.
Route/error observation
Selected normal route
Stage/owner review
Incomplete stage trace
Outcome evidence scope
No authorization inference
The complete source trace was requested
Presentation, handler and completion observations within the same requestRef and terminal-owner scope are required. Adding raw credentials or the full response body does not resolve a stage gap.
Route/error observation
Request correlation scope
Stage/owner review
Complete trace evidence required
Outcome evidence scope
UNKNOWN: execution outcome
The partial-trace conclusion stayed bounded
Route selection is known; handler execution and terminal outcome remain UNKNOWN within this partial scope. Expected traces cannot substitute for observed traces.
Route/error observation
Known: selected route
Stage/owner review
UNKNOWN: later stages
Outcome evidence scope
UNKNOWN: terminal outcome

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Correlate selection and stage trace

Correlate harmless requestRef, method, parsed pathname, query view, and selected handler. GET /notes?view=plain records pathname /notes, noteRead, and expected stages. A method mismatch has handlerInvoked=false with 405 with Allow: GET, while an absent route has handlerInvoked=false with 404. Real telemetry mappings depend on server/framework; the artifact is not a runtime access-log format.

Inspect middleware pass/terminal/error decisions within one request context. Expect request-ref and presentation before handler entry. Missing logs do not prove a stage did not run; mark the source field absent. Correct route selection does not establish authorization. Track required access decisions separately for personalized handlers.

Separate final response from business result

Correlate terminal owner and final status/content bytes with the selected exchange. Compare normal Routed note status 200/body 11 bytes, controlled 500 Service unavailable, method-mismatch 405 Method not allowed, and missing 404 Route not found. Keep the error beforeHeaders condition explicit; do not infer post-header stream behavior from this fixture.

Record server writableEnded/finish separately from client content receipt. Show the guard blocking second logical completion and one response end through local decision metadata, without sending malformed output. Persistence evidence is absent for this read fixture. Stateful services require storage commit/error observations, so transport finish must not gain an unsupported committed=true field.

The artifact XPath counts response observations with commitClaim=true despite persistenceObserved=false. Benign reads yield 0; an unsupported commit interpretation yields 1. Correlation stays inside the supplied response element rather than database auditing or a distributed-transaction query. With no element, 0 alone establishes neither a correct nor an incorrect commit.

Make pass and terminal decisions one control flow

Route and middleware order controls progression, not just log layout. Do not enter a personalized handler before its required request context is ready; complete any required access decision separately before handler execution. Middleware either ends the cycle or explicitly passes control onward. A denial or error must not continue into the normal handler, and the response owner must reject a second completion. In Express, follow the next and error-handling middleware contract; this small dispatcher does not establish that Express was executed.

Verify the expected stage order and single terminal outcome for the normal route. Preserve 405 with Allow: GET for a method mismatch, 404 for a missing route, and 500 for the beforeHeaders error branch while checking that the handler was not invoked or did not produce normal success. These statuses are the example’s explicit dispatch policy, not automatic behavior of every framework. Missing stage evidence is unknown; final status alone cannot prove middleware or authorization execution.

NOW APPLY IT TO THE CASE

Which business outcome do route matching and finish not prove?

The public-read route is selected by method/path; middleware context, terminal ownership and client knowledge remain within their boundaries.

Reconstruct decision order for input, server processing and response in the case. Parsed or valid data is not a completed operation; identify each owner and its condition.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Route selection and terminal-response ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "routeTable": [
    {
      "method": "GET",
      "pathname": "/notes",
      "handler": "noteRead"
    },
    {
      "method": "GET",
      "pathname": "/notes/fail",
      "handler": "fixtureReadFailure"
    }
  ],
  "normal": {
    "method": "GET",
    "target": "/notes?view=plain",
    "pathname": "/notes",
    "query": {
      "view": "plain"
    },
    "requestRef": "read-a",
    "trace": [
      "request-ref",
      "route",
      "presentation",
      "handler"
    ],
    "handlerInvoked": true,
    "status": 200,
    "body": "Routed note",
    "contentOctets": 11,
    "terminalOwner": "noteRead"
  },
  "methodMismatch": {
    "method": "POST",
    "pathname": "/notes",
    "bodyOctets": 0,
    "status": 405,
    "allow": "GET",
    "body": "Method not allowed",
    "handlerInvoked": false
  },
  "routeAbsent": {
    "method": "GET",
    "pathname": "/absent",
    "status": 404,
    "body": "Route not found",
    "handlerInvoked": false
  },
  "handlerError": {
    "method": "GET",
    "pathname": "/notes/fail",
    "trace": [
      "request-ref",
      "route",
      "presentation",
      "handler",
      "error-map"
    ],
    "beforeHeaders": true,
    "status": 500,
    "body": "Service unavailable",
    "terminalOwner": "error-map"
  },
  "completion": {
    "endCalls": 1,
    "secondLogicalCompletionBlocked": true,
    "headersSentAfterTerminal": true,
    "writableEndedAfterTerminal": true,
    "finishMeansOSHandOff": true,
    "finishProvesClientReceived": false,
    "persistenceOperation": null,
    "commitProven": false
  },
  "selector": {
    "language": "XPath",
    "xml": "<observations><response finish=\"true\" persistenceObserved=\"false\" commitClaim=\"false\"/></observations>",
    "xpath": "count(/observations/response[@persistenceObserved=\"false\" and @commitClaim=\"true\"])",
    "expected": 0,
    "positiveFixtureXml": "<observations><response finish=\"true\" persistenceObserved=\"false\" commitClaim=\"true\"/></observations>",
    "positiveExpected": 1,
    "scope": "Only authored protocol-decision observations, not product log field names or a live HTTP capture.",
    "missingFieldBehavior": "Missing observation is insufficient evidence; zero matches is not proof of correct runtime behavior."
  }
}

routeTable / normal: Separate method/path selection and query with expected local stages.
methodMismatch / routeAbsent: Distinct terminal decisions that never invoke a handler.
handlerError / completion: Controlled pre-header error and transport/business completion distinction.

Inert public-read pipeline with supplied manual Node matching/405/error policy. It is not Express execution, a database transaction, or a malformed-transfer test.

Two reality checks

A route match and middleware presence prove permission.

Selection chooses a code target; applying required access decisions to that route in order is a separate contract.

ServerResponse finish proves client success and database commit.

Finish is transmission handoff to the OS; client content and persistence results need separate observations.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

POST /notes uses an existing path, but the route table defines only GET. Is the handler invoked?

Yes; matching the pathname permits every method.
No; 405 and Allow:GET.

Read the explained answer

No; 405 and Allow:GET. — The path is known but the method mismatches; handlerInvoked=false. Missing-route 404 is another branch.

Does a response finish event prove client receipt?

Selected lesson artifact fields; teaching example

completion.endCalls: 1
completion.finishMeansOSHandOff: true
completion.finishProvesClientReceived: false

No; selected finish is an OS-handoff boundary.
Yes; finish acknowledges that the client parsed the body.

Read the explained answer

No; selected finish is an OS-handoff boundary. — finishProvesClientReceived=false; do not turn local response-end completion into remote confirmation.

Why must a second response write be prevented when a pre-response handler error maps to 500? What is unknown about commit?

Read the explained answer

Because the error is beforeHeaders, error-map can own the response; endCalls=1 and secondLogicalCompletionBlocked prevent multiple terminal outcomes. PersistenceOperation is null, so finish/500/200 prove no business commit. This ordered teaching pipeline does not establish arbitrary framework error-handling implementations.

□ I identified one terminal-response owner.

□ I did not count response completion as a business commit.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

Express — Routing guideRouting · Route methods · Route paths · Route handlers
Express — Using middlewareUsing middleware · Middleware sub-stacks · Multiple route handlers · Error-handling middleware
Node.js v24.13.0 — HTTP APIHTTP · http.createServer([options][, requestListener]) · Class: http.ServerResponse · http.ServerResponse Event: finish · response.writableEnded · response.writableFinished · response.headersSent · response.strictContentLength
Node.js Learn — Anatomy of an HTTP TransactionCreate the Server · Method, URL and Headers · HTTP Status Code · Sending Response Body

YOUR NOTES / THIS BROWSER

Routing, middleware, and handlers

1. Core · Mechanism

Ordered GET

Method mismatch

Route absent

Handler error

A framework organizes execution

Middleware produces state or ends the cycle

One response owner and bounded completion

2. Red · Trust & Impact

Method mismatch

Finish boundary

Do not equate route matching with permission

Overtrusting completion

3. Blue · Secure development & defense

Pre-header error

Trace gap

Correlate selection and stage trace

Separate final response from business result

Make pass and terminal decisions one control flow

Which business outcome do route matching and finish not prove?

Two reality checks

POST /notes uses an existing path, but the route table defines only GET. Is the handler invoked?

Does a response finish event prove client receipt?

Why must a second response write be prevented when a pre-response handler error maps to 500? What is unknown about commit?

Sources and scope