Json Rpc Log Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. Despite the "Laravel/PHP" framing, the realistic first decision is whether you can use it at all: tourze/json-rpc-log-bundle ships a *Bundle class and expects Symfony's kernel/bundle registration, so composer require into a pure Laravel app will install but not wire itself up. In Laravel, treat it as a source of reference implementation (entity, subscriber, config tree) rather than a drop-in dependency, unless you're bridging Symfony components into your app.

Minimal path if you are on Symfony:

composer require tourze/json-rpc-log-bundle:^2.0

Then register the bundle in config/bundles.php and inspect the configuration tree before writing any code:

php bin/console config:dump-reference json_rpc_log
php bin/console debug:container --tag=json_rpc_log

Where to look first, in order:

1. src/DependencyInjection/Configuration.php — the authoritative list of options; the README usually lags behind.
2. The event subscriber / listener that actually captures calls — this tells you what gets persisted (method, params, result, error, duration, user?) and when.
3. src/Entity/*Log.php plus the matching Doctrine migration — this is your retention and indexing surface.
4. composer.json of the tag you installed — check the PHP and symfony/* constraints against your app.

First use case to validate before committing: capture a single JSON-RPC call end-to-end and confirm you get a row with the method name, request payload, response/error, and timing. If that doesn't work out of the box, the bundle is providing less than you need and you should reassess.

On 2.0.0 specifically: the release notes contain only a changelog compare link, no migration guide, no BC-break list, no feature summary. A major bump from 1.0.2 with zero prose is the single most important fact in this assessment. Read the diff between 1.0.2 and 2.0.0 before upgrading anything.

Implementation Patterns

Automatic capture via the bundle's subscriber. The intended pattern is zero-code: the bundle registers a listener that records JSON-RPC traffic as a side effect. Use this when you want audit/observability without touching call sites. Verify what happens on exceptions — whether failed calls are logged as rows, as errors, or dropped.

Decorator around your JSON-RPC client. More portable, and the pattern that survives if you move off Symfony. Wrap the transport/client and log before/after:

final class LoggingJsonRpcClient implements JsonRpcClientInterface
{
    public function __construct(
        private JsonRpcClientInterface $inner,
        private JsonRpcLogger $logger, // the bundle's service, or a Laravel-side equivalent
    ) {}

    public function call(string $method, array $params): mixed
    {
        $start = microtime(true);
        try {
            $result = $this->inner->call($method, $params);
            $this->logger->success($method, $params, $result, microtime(true) - $start);
            return $result;
        } catch (\Throwable $e) {
            $this->logger->failure($method, $params, $e, microtime(true) - $start);
            throw $e;
        }
    }
}

This gives you a seam for redaction, sampling, and testing that the bundle's own subscriber likely doesn't expose.

Dual-sink logging. Write structured records to the database for queryability and to a PSR logger for tailing. Logs stored only in the DB are useless during an incident when the DB is the thing that's slow; logs only in files are useless when you need "show me every call to order.create by user 42 last week."

Laravel-side integration. If you're reusing the concept rather than the package: a queued listener on your RPC dispatch event, a json_rpc_logs table with indexes on (method, created_at) and (user_id, created_at), and a scheduled prune command. Keep the write path off the request's critical path via dispatch()->afterResponse() or a queue.

Testing. Point the logger at an in-memory or array handler in tests and assert on method/params rather than on the DB, so a schema change in the bundle doesn't break your suite. For the decorator pattern above, a fake inner client plus a spy logger makes JSON-RPC edge cases (timeouts, malformed responses) trivial to cover.

Gotchas and Tips

2.0.0 is undocumented. No release notes beyond a compare link means you cannot assume a safe upgrade. Concretely:

# inspect what actually changed before touching composer.json
git diff 1.0.2..2.0.0 -- src/ composer.json
composer why-not tourze/json-rpc-log-bundle 2.0.0

Look specifically for renamed config keys, changed service IDs, entity/table renames (these need migrations), changed constructor signatures on the logger service (breaks your decorator), and bumped symfony/* constraints that conflict with your framework version.

Pin and stage. Until someone writes the upgrade note you don't have, use "tourze/json-rpc-log-bundle": "^2.0" only after running the full test suite against a branch. If you're on 1.0.2 in production, ~1.0.2 is a defensible holding position.

Config key drift between majors. Symfony bundles commonly rename the root alias between majors. If config:dump-reference returns "no extension found," the alias changed — grep DependencyInjection/Configuration.php for ->rootNode() / ->getRootNode().

Schema changes need migrations. A log-bundle major version is a common moment for column type changes (e.g. params from text to json, or splitting request/response). Run doctrine:schema:validate and diff the generated migration rather than letting schema:update run blind on a populated log table.

Log volume will surprise you. JSON-RPC params and responses can be large and can contain tokens, PII, and full payloads. Before enabling capture in production, confirm there's a truncation/size cap and decide explicitly what gets redacted. An unbounded log table on a busy RPC endpoint becomes an outage.

PII and secrets in payloads. Auth tokens and passwords frequently ride inside params. If the bundle has no redaction hook, the decorator pattern above is where you add it — do it before the first production deploy, not after.

Retention is your job. Bundles log; they rarely prune. Add a scheduled cleanup and an index that supports it (created_at), otherwise the table grows until someone notices.

Async/queue contexts. If RPC calls happen inside Messenger workers, confirm the logger doesn't depend on request-scoped state (security token, request stack). Worker-side logging that silently no-ops is a common failure mode.

Extension points to check for in 2.0: whether the storage backend is swappable (DB vs PSR-3), whether there's a sampler/rate limiter, and whether the captured fields are configurable. If 2.0 didn't add at least one of these, the major bump was likely structural (Symfony version floor, PHP version floor) rather than functional — which changes how urgently you should adopt it.

Overall recommendation: evaluate, don't adopt blindly. The package is small-scope and single-purpose, and 2.0.0's lack of a changelog means the upgrade cost is unknown. Time-box a spike: install, dump the config reference, capture one call, check the diff. If any of those three steps is unclear, port the ~100 lines of logging logic into your own codebase — you'll own the schema, the redaction, and the retention policy, which is where the real risk lives anyway.