Set up the Record Integrity services
Vera 2026.2 introduces two new services that power Record Integrity: vera.api.recordintegrity and vera.worker.recordintegrity. You need to add both services to your deployment, provision a MongoDB database for the worker, and confirm that the Jira and qTest workers are updated. This topic covers what to add and how to verify the deployment.
Before you start
Before you deploy the Record Integrity services, confirm the following:
-
You have access to your Vera deployment configuration (Docker Compose or Helm chart).
-
Your MongoDB instance is running and accessible to other Vera services. The Record Integrity worker uses a dedicated database on the same MongoDB instance as the rest of Vera.
-
You have the 2026.2 Docker images for
vera.worker.jiraandvera.worker.qtestavailable in your registry. Both workers ship with new consumers that handle Auto-fix requests.
Add the services to your deployment
Add vera.api.recordintegrity and vera.worker.recordintegrity alongside the existing Vera services. Both follow the same container and health check patterns as other vera.api.* and vera.worker.* services.
For Docker Compose deployments, the updated docker-compose.yml file includes the new service definitions. For Helm deployments, update your chart values to include the worker-recordintegrity and api-recordintegrity templates per your vera-helm chart documentation.
The services expose liveness and readiness endpoints that follow the same pattern as other Vera services. Add health checks to your deployment configuration accordingly.
Provision the Record Integrity database
The Record Integrity worker stores sync issues, triage state, and audit entries in a dedicated MongoDB database. The database is created automatically on first startup if the connection user has the required permissions. The worker manages its own indexes.
If you provision MongoDB databases ahead of time, create a database for the Record Integrity worker on the same MongoDB instance you use for the rest of Vera. Confirm that the connection string used by vera.worker.recordintegrity can read, write, and create indexes in that database.
Update the Jira and qTest workers
Auto-fix from the Record Integrity queue uses a message bus to push corrective updates to the source system. vera.worker.recordintegrity publishes a push command on the bus; vera.worker.jira and vera.worker.qtest consume the command, call the external API, and publish completion back to the bus. The Record Integrity worker waits for completion before reporting a result to the administrator.
If vera.worker.jira or vera.worker.qtest isn't on the 2026.2 image, the new push consumer isn't present and Auto-fix requests for that source system time out. Roll out the new vera.worker.recordintegrity image together with the matching 2026.2 images for vera.worker.jira and vera.worker.qtest.
To confirm the workers are ready, check the startup logs for the registration of RecordIntegrityPushToSourceCommandConsumer in each of the Jira and qTest workers. If you don't see the registration message, the worker is running an older image.
Verify the deployment
After you bring up the updated stack, confirm that the Record Integrity services are healthy:
-
Check the container logs for
vera.api.recordintegrityandvera.worker.recordintegrityfor startup errors. Both services log at the same level as other Vera services. -
Send a request to the liveness endpoint of
vera.api.recordintegrity. A successful response confirms the service started correctly. -
In the Vera web portal, go to Administration > Source Record Management > Record Integrity and confirm the queue loads. If the page is missing or the queue fails to load, the API or the worker may not have registered correctly.
-
Run a test Auto-fix on a non-production sync issue and confirm the result returns within the expected window. If the action times out, recheck the Jira and qTest worker images.
Upgrade notes
If you're upgrading an existing Vera deployment to 2026.2, you need to add the Record Integrity services as new services. They don't replace any existing service. Also check for the following:
-
Update your Docker Compose or Helm chart to include the new service definitions and the matching 2026.2 images for
vera.worker.jiraandvera.worker.qtest. -
MongoDB may require new indexes for the Record Integrity collections. These are applied automatically on first startup.
-
For general upgrade steps, see Upgrade to 2026.2.
What's next
Now that the services are running, here's what you can do next:
-
Record Integrity to triage and resolve sync issues from the queue.
-
Mismatch Notification to decide who gets an email when Vera detects a new sync issue.