FeathersJS Service Hooks Not Executing: Diagnostic Guide

Recognizable Condition

Your FeathersJS service methods (create, update, patch, remove, find) complete and return data, but registered before/after/error hooks do not run, run out of order, or silently fail without throwing. The service responds normally, yet logging, validation, or side-effect logic inside hooks never executes.

Cause and Diagnostic Quick-Reference

Ordered Diagnostic Checks

Check 1: Verify Hook Registration Timing and Path

Run this check in your application bootstrap code (typically app.js or a service configuration file). Confirm:

1. The service is initialized via app.use('/path', new MyService()) before hooks are registered.
2. Hook registration uses the exact same path string including leading slash: app.service('/path').hooks({ before: { create: [myHook] } }).
3. You are using the hook registration syntax for your Feathers major version. In v4, app.service('path').hooks({...}); in v5, app.service('path').hooks({...}) works but the recommended pattern is service.hooks({...}) on the service class itself.

Risk: Registering hooks before app.use() attaches them to a non-existent service, silently creating a new empty service instance.

Check 2: Add Execution Logging Inside the Suspect Hook

Edit the hook file directly. Insert a log at the very first line:

// my-hook.js
module.exports = () => async context => {
  console.log('[HOOK ENTER]', context.type, context.method, context.path);
  // ... existing logic
  console.log('[HOOK EXIT]', context.type, context.method);
  return context;
};

Invoke the service method through the Feathers client (not direct HTTP fetch) so the full transport stack runs:

// client test
const client = feathers();
client.configure(feathers.rest(baseUrl).fetch(fetch));
await client.service('path').create({ test: true });

Observe console output. If [HOOK ENTER] never appears, the hook is not in the chain. If ENTER appears but EXIT does not, the hook is short-circuiting (see Check 3).

Check 3: Test Across REST and Real-Time Transports

Run the same service call through both transports in quick succession:

// REST
const restClient = feathers();
restClient.configure(feathers.rest(baseUrl).fetch(fetch));
await restClient.service('path').create({ via: 'rest' });

// Socket.io
const socketClient = feathers();
socketClient.configure(feathers.socketio(io()));
await socketClient.service('path').create({ via: 'socketio' });

If hooks fire on one transport but not the other, inspect transport-specific middleware (e.g., express.json() ordering, Socket.io authentication middleware) that may terminate the request before reaching the service layer.

Check 4: Search for Direct Database Adapter Bypass

Grep your codebase for direct model usage:

grep -r "\.find(" --include="*.js" --include="*.ts" | grep -v "service\.find"
grep -r "Model\." --include="*.js" --include="*.ts"

Any call to UserModel.find(), db.collection.find(), or ORM methods directly on the model bypasses Feathers service hooks entirely. Refactor these to app.service('users').find(params).

Fixes Tied to Findings

Fix: Re-register Hooks on Correct Service Instance

Move hook registration after service initialization and ensure path matches exactly:

// app.js (v4/v5 compatible)
const MyService = require('./services/my-service');
app.use('/my-service', new MyService());

// Register hooks AFTER use()
app.service('/my-service').hooks({
  before: {
    create: [validateInput, setDefaults],
    find: [authenticate('jwt')]
  },
  after: {
    create: [logActivity],
    all: [populateRelations]
  },
  error: {
    all: [handleError]
  }
});

For v5 class-based services, define hooks on the class:

// services/my-service.js (v5)
const { Service } = require('@feathersjs/feathers');
const { hooks } = require('@feathersjs/hooks');

class MyService extends Service {
  // ... methods
}

module.exports = MyService;

// In app.js
const MyService = require('./services/my-service');
app.use('/my-service', new MyService());
// Hooks can also be added here if not on class

Fix: Return/Await Context in Async Hooks

Every async hook must return the context (or a modified context). Missing return breaks the chain:

// BROKEN - chain stops here
module.exports = () => async context => {
  await doAsyncWork(context.data);
  // no return -> subsequent hooks never run
};

// FIXED
module.exports = () => async context => {
  await doAsyncWork(context.data);
  return context; // or return { ...context, data: newData };
};

If you need to modify the context, return the modified object. Returning undefined or nothing is equivalent to breaking the chain.

Fix: Route All Mutations Through Service Layer

Replace direct model calls with service calls. Example refactor:

// BEFORE - bypasses hooks
const User = require('../models/User');
async function createUser(data) {
  return User.create(data); // hooks never fire
}

// AFTER - triggers hooks
const app = require('../app');
async function createUser(data) {
  return app.service('users').create(data); // before/after/error hooks run
}

For internal server-to-server calls, obtain the app instance and call app.service('path').method(). This ensures hooks execute even without HTTP transport.

Escalation Criteria

Escalate to deeper debugging when:

• All four checks pass but hooks still do not execute — suspect version mismatch between @feathersjs/feathers and hook plugins; verify package.json and consult exact version docs.
• Hooks execute but error hooks never catch thrown errors — verify error hook registration uses error: { all: [handler] } and that errors are thrown (not returned) in service methods.
• Hook order differs from registration order — Feathers sorts hooks by type (all then method-specific) and registration sequence; log context.type and context.method to map actual order.
• TypeScript compilation strips hook metadata — ensure emitDecoratorMetadata and experimentalDecorators are enabled if using decorators.

Verification Steps

1. Inspect package.json for @feathersjs/feathers major version. Match hook registration syntax to that version's documentation.
2. Add temporary console.log inside the hook, call the service via Feathers client, confirm log appears.
3. Reproduce the call over REST and Socket.io in parallel; compare hook execution.
4. After applying fixes, run integration tests covering create/update/patch/remove/find across both transports.

Limitations

This guide covers the most common hook execution failures in Feathers v4 and v5. It does not address custom transport adapters, third-party hook libraries that wrap Feathers hooks, or application-level error handlers that swallow hook errors. If your stack includes those, extend the diagnostic checks accordingly.