Pepy

A derived copy drifts whenever the source schema or the conversion logic changes on its own. A column added to a model does not reach search, or a converted value is indexed in the wrong shape, and the first sign of it is a filter returning the wrong set. Neither store reports an error, because from each side the data it holds is valid.

Each model declares which of its columns matter to search in an explicit field list, and has a matching pair of conversion functions between the database shape and the search shape. Adding a column is therefore three coordinated changes, not one: the migration, the field list, and both converters. I built and maintained that across the models I worked on.

The mapping between the two stores is declared in code next to the model, not inferred by whatever the indexer read. Adding a column therefore shows up in review when one of the three parts is missing, instead of passing and returning the wrong set in search later.

A derived copy needs a rebuild path, because it will eventually be wrong. Rebuilding by emptying and repopulating the index that search is currently reading from would take search down for the length of the reindex.

I wrote migrations and seeders that reindex tables into Elasticsearch, either one model at a time or across the board, so a rebuild is a repeatable command instead of a manual operation. The build script checks whether an index alias exists for a given model and creates it if not. With the alias in place, a rebuild indexes into a new index and repoints the alias to it, so the live index is never truncated.

Reindexing became a repeatable operation without requiring the live search index to be emptied first. I confirmed the production Elasticsearch and Node versions with DevOps before relying on any of it, and had them verify the affected index in production after a reindex rather than assuming it had worked.

Pepy needed to pull task data from the tools teams already used, so the Trello, GitLab, and Google connections had to be built, not taken from an SDK. Most of the work was not the code-for-token exchange but the failure cases around it and the multi-tenant setup.

I built the flows and the recovery around them. When a stored token has been invalidated upstream, it has to be removed along with the saved board and list settings, otherwise the user is left with a dead connection they cannot re-establish. Board and list names are stored alongside their identifiers so the settings screen can show names instead of numbers. Trello will not return a user's email unless the correct scope was requested at authorization time, and adding that scope later means asking every connected user to reauthorize, so it had to be settled before rollout. On the Google side, an unverified tenant needed its redirect URI rewritten to the registration subdomain, since one registered callback does not cover every tenant.

Partway through, ownership of the Trello token moved to the frontend, so I rebuilt that connection against the new arrangement and closed the original merge request instead of trying to salvage it.

A user can disconnect and reconnect without support intervention, tenants that are not yet verified can still complete a Google sign-in, and the required Trello scope was established before rollout, avoiding a later forced reauthorization of connected users. Checking that the token row had been removed would have been the easy version. I ran the disconnect and reconnect path end to end. QA and I then both signed in from a tenant whose subdomain was not registered as a Google callback, and the rewritten redirect URI carried the sign-in through.