Problem
Both git-proxy-java and the original finos/git-proxy (Node.js) use a `pushes` collection in MongoDB. If an operator points git-proxy-java at an existing finos/git-proxy database, documents will silently co-exist but the schemas are incompatible — Java will fail to deserialise old Node.js documents (which have a `steps` array and no `resolvedUser`) and the Node app will see unexpected documents in its push queue.
The two codebases are fundamentally different and no data migration path is provided or planned. The correct upgrade path is a dedicated logical database or a separate MongoDB instance.
Known collection overlaps
| Collection |
finos/git-proxy |
git-proxy-java |
| `pushes` |
push queue records |
push audit records ← direct schema clash |
| `repos` |
repository allow/deny config |
(not used — git-proxy-java uses `access_rules`) |
| `users` |
user accounts |
(not used in Mongo yet) |
Proposed mitigations
-
Startup detection: on first connect, sample a document from the `pushes` collection. If it contains a `steps` array (the Node.js shape) and no `resolvedUser` field, log a prominent `WARN` (or `ERROR`) message explaining the collision risk and recommending a dedicated database.
-
Documentation: update `docs/CONFIGURATION.md` and the Docker Compose Mongo example to explicitly recommend a separate logical database name (e.g. `gitproxyjava`) rather than the generic `gitproxy` that finos/git-proxy defaults to.
-
(Optional) Refuse to start if a collision is detected, controlled by a config flag `database.mongo.fail-on-schema-conflict: true` (default `false` to avoid breaking existing intentional setups).
Out of scope
- Data migration from finos/git-proxy to git-proxy-java
- Schema compatibility or dual-write support
Problem
Both git-proxy-java and the original finos/git-proxy (Node.js) use a `pushes` collection in MongoDB. If an operator points git-proxy-java at an existing finos/git-proxy database, documents will silently co-exist but the schemas are incompatible — Java will fail to deserialise old Node.js documents (which have a `steps` array and no `resolvedUser`) and the Node app will see unexpected documents in its push queue.
The two codebases are fundamentally different and no data migration path is provided or planned. The correct upgrade path is a dedicated logical database or a separate MongoDB instance.
Known collection overlaps
Proposed mitigations
Startup detection: on first connect, sample a document from the `pushes` collection. If it contains a `steps` array (the Node.js shape) and no `resolvedUser` field, log a prominent `WARN` (or `ERROR`) message explaining the collision risk and recommending a dedicated database.
Documentation: update `docs/CONFIGURATION.md` and the Docker Compose Mongo example to explicitly recommend a separate logical database name (e.g. `gitproxyjava`) rather than the generic `gitproxy` that finos/git-proxy defaults to.
(Optional) Refuse to start if a collision is detected, controlled by a config flag `database.mongo.fail-on-schema-conflict: true` (default `false` to avoid breaking existing intentional setups).
Out of scope