CodeVetter · Repo Unpack · Behavior traces
redwoodjs/redwood
The investigation followed browser startup, development-command startup, todo creation and persistence, authentication context construction, and background-job execution through their relevant source files. These traces describe source call order, not observed execution. The todo fixture demonstrates the client-to-service data contract but contains a legacy GraphQL bootstrap, so the current server boundary is substantiated separately with test-project and framework sources. Job scheduling and consumption form an additional end-to-end persistence flow.
- Browser startup: index.jsx finds redwood-app → hydrateRoot or createRoot.render → App → FatalErrorBoundary → RedwoodProvider → RedwoodApolloProvider → supplied Routes.
- Routing continuation: Router → LocationProvider → LocationAwareRouter → analyzeRoutes → matchPath/parseSearch → ParamsProvider → WrappedPage → ActiveRouteLoader → LazyRouteComponent.
- Development startup: CLI resolves cwd → sets RWJS_CWD → loadEnvFiles → main/runYargs → registered dev handler dynamically imports devHandler.handler.
- Development continuation: devHandler reads paths/config → checks configured ports → generates Prisma client for the API side → constructs API/web/gen commands → concurrently starts eligible processes; port conflicts exit instead of automatically switching ports.
- Todo creation, client phase: HomePage renders AddTodo → AddTodoControl.handleChange stores input → handleSubmit calls submitTodo and clears input → AddTodo.submitTodo calls createTodo with variables and an optimistic Todo.
- Todo creation, persistence contract: CREATE_TODO selects createTodo(body) → SDL declares that mutation → matching service export calls db.todo.create → SQLite schema supplies an autoincrement id and default off status → Apollo update appends the response to TODOS.
- Current GraphQL startup: test-project creates a dbAuth decoder and passes SDL/services/directives/logger to createGraphQLHandler → createGraphQLYoga → makeMergedSchema → ordered plugin construction → createYoga.
- Authenticated operation: Apollo withToken obtains credentials → authMiddleware sets headers → Yoga auth plugin calls getAuthenticationContext → decoders run → getCurrentUser resolves application identity → extendContext adds currentUser.
- dbAuth login: constructor extracts/decrypts the session → invoke calls init/normalizeRequest → validates method and verb → dispatches login → _verifyUser → configured login.handler → _loginResponse → encrypted session and provider cookies plus csrf-token response header.
- Job submission: JobManager.createScheduler returns a scheduling function → Scheduler.schedule → buildPayload/computeRunAt → adapter.schedule → PrismaAdapter creates the database record with serialized invocation metadata.
- Job consumption: Worker.run → #work → adapter.find → conditional Prisma lock → Executor.perform → loadJob dynamically imports the compiled job → job.perform(...args) → adapter.success or adapter.error/failure.