The connector nobody had built yet
Apache Flink didn't have an official SQL connector for Qdrant, the vector database. I use both — Flink for streaming pipelines, Qdrant for the embedding store downstream — so I built flink-connector-qdrant to close that gap: a Flink SQL sink that upserts points into Qdrant directly from a streaming job, no glue code in between.
It shipped, people started using it, and then an architect reviewing it on LinkedIn pointed out something I'd missed.
The bug
My upsert path stored a version number per point so that if the same ID arrived twice, the connector could tell which write was newer and keep that one. Straightforward, except for one thing: storing a version number alone doesn't guarantee atomic ordering under concurrent writers.
Picture two parallel sink tasks racing on the same point ID. Writer A has version 5, writer B has version 6. There's no guarantee B's write lands after A's just because its version number is higher — depending on timing, A can still land last and silently overwrite the newer data. A bare version field tells you which value should win; it doesn't make the database enforce that when two writes are in flight at the same time.
That's a real data-correctness bug, not a style nit. In a streaming sink, "newer data wins" is the whole point of upserts.
The fix
I added an opt-in version-field option: when configured, the connector deduplicates by highest version within a batch before the Qdrant write goes out, instead of trusting Qdrant to sort it out writer by writer. Same version field the architect was looking at, but the ordering guarantee now lives on my side of the wire, where I actually control it.
I shipped it as three separate commits — a fix for the dedup logic, a feat for the opt-in config surface, and a docs commit explaining when to turn it on — instead of squashing it into one. Reviewing a bug fix is easier when you're not also reviewing a new feature flag in the same diff, and it meant the person who raised the issue could actually see the fix land commit by commit rather than taking my word for it.
The other repo
Same week, I pushed multi-cluster support into apache-flink-mcp-server — it lets AI assistants talk to a Flink cluster over MCP (Model Context Protocol), but until now it only knew about one cluster at a time, which doesn't match how anyone actually runs Flink. It also picked up its listing on the Glama MCP directory.
Neither of these projects is glamorous. They're the kind of infrastructure that's only interesting when it's wrong. But getting real review from someone who actually reads the code, and being able to turn that into a fix the same week, is the part of open source that's worth writing about.
If you're running vector search behind a Flink pipeline, or you want an AI assistant that can actually see what's happening in your Flink cluster, both repos are open for issues and PRs.
