Notifications

Per the JSON-RPC 2.0 specification, a request without an id is a notification: the client does not wait for a result. The server does not return a response to it, and a single notification over HTTP gets 204 No Content with an empty body.

curl -i -X POST https://example.com/rpc \
  -H 'Content-Type: application/json' -H 'Ufo-RPC-Token: <token>' \
  -d '{"jsonrpc": "2.0", "method": "audit.log", "params": {"event": "login"}}'
# HTTP/1.1 204 No Content

The method signature does not change; its result is discarded. So notifications suit "fire and forget" actions: auditing, metrics, sending messages.

When the method runs

The method runs on the rpc.post_response event, i.e. after the response has been sent to the client:

• under PHP-FPM, after fastcgi_finish_request(), so the client does not wait;
• in other SAPIs (Apache mod_php, the built-in server) the method also runs, even if the client has already closed the connection (since 10.3), but the HTTP worker stays busy until the method finishes.

Execution is logged via LoggerInterface at the info level.

Detached execution

Rare long-running notifications can be executed in a detached ufo:rpc:process process so they do not hold the HTTP worker:

ufo_json_rpc:
    notification:
        process: true
        process_count: 2    # detached processes running concurrently (1–10); when all are busy, execution happens inline

The request is executed exactly once: if the detached process has not picked it up within 3 seconds, the worker executes it itself. The same applies to $rpc.callback.

Notifications in batch

In a batch, a notification is executed according to the batch mode, but there is no response for it. A batch containing only notifications returns 204 with no body.

Upgrading from 10.0

Clients that sent requests without an id and waited for a result must pass an id.