meteroid-oss/meteroid: technical due diligence, read from its repository

172 test files against 1,748 source files (9.8%). This does not measure whether the tests are good, only whether enough of them exist for the codebase to be changed safely by someone who did not write it — which is exactly the situation after an acquisition.

55 of 385 commits in the last 24 months changed over 2,000 lines of code, not counting reformatting, renames, vendored or generated code. A change that size is rarely reviewed line by line. Ask how they were reviewed, and what made them that large.

Within a single package: dates: date-fns, dayjs; state management: jotai, zustand. Each duplicate is bundle size, two ways of doing the same thing in one codebase, and two upgrade paths to maintain. It is usually the residue of a migration that stopped halfway.

Strings shaped like credentials appear only where fakes are usual: test fixtures, examples, documentation, placeholders and local stacks. They are almost always fakes. Ask someone to confirm that none of them works anywhere, because a real key in a development file is still a real key.

No USER instruction switches away from root, so the process runs with full privileges inside the container. It is a one-line fix and an ordinary expectation, which is why its absence is worth asking about: it usually says more about whether anyone has reviewed the deployment than about this container specifically.

75 of 3,254 locked dependencies match 195 published advisories in OSV, 120 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version. This lockfile pins development tools alongside what ships and does not say which is which, so some of these may never reach a user.

The build configuration emits source maps for production, so the original source, with its comments and structure, is downloadable by every visitor. Upload them to an error tracker and keep them off the public server instead.

Nothing in the service carries a request or correlation id, and there is no tracing. When a customer reports a failure, the log lines that belong to their request cannot be picked out from everyone else's.

Both probes call the same endpoint. When a dependency slows down, the liveness probe fails with the readiness probe, so the platform restarts pods that only needed taking out of rotation, and a partial outage becomes a full one. Liveness should ask whether the process is alive; readiness whether it can serve.