DEV Community: Mohamed Elgohary

Valid product, wrong supplier: moving an ownership rule into the database

Mohamed Elgohary — Tue, 10 Nov 2026 21:54:05 +0000

TL;DR

In EgyGomla, a request for a sample could name supplier A and a product that belonged to supplier B. Every constraint in the database accepted it.
The only thing refusing that pair was one if in one repository method. It protected that code path and no other.
A composite foreign key on (product_id, supplier_organization_id) moved the rule into the database. I kept the application check so callers still get a clear error.
No production incident is behind this. I found it while reviewing the schema. The fix enforces one stored relationship, not authorization in general.

The shape of the problem

EgyGomla is a B2B sourcing platform I built for Egyptian traders. Two of its tables hold sample requests and private-label requests. Each row carries a supplier and, optionally, a catalogue product.

The foreign key from the request to the product named only catalog_products(id). So the database asked one question: does this product exist? It never asked whether the product belongs to the supplier written on the same row.

That means a row pairing supplier A with supplier B's product satisfied every constraint. The product is real and the supplier is real. The relationship is wrong.

There was a check. The service verified that the product belonged to the supplier, so requests arriving through the API were covered. My own migration comment describes the weakness better than I would paraphrase it: that check protects the path that runs it and no other, "not a repair script, not a future module, not a bulk import".

I want to be exact about the scope here. I did not find corrupted data, and no customer was affected. This was a gap between what the application enforced and what the database enforced, and the cheapest time to close it is before something writes a bad row.

The fix

The rule moves into the key itself. First, the parent table gets a unique constraint over the pair, so the pair can be referenced:

ALTER TABLE "catalog_products"
  ADD CONSTRAINT "catalog_products_id_supplier_organization_id_key"
  UNIQUE ("id", "supplier_organization_id");

This adds no real restriction. id is already the primary key, so any (id, supplier) pair is already unique. The constraint exists only so that something can point at the pair.

Then the child tables swap their single-column key for a composite one:

ALTER TABLE "sample_requests"
  DROP CONSTRAINT "sample_requests_product_id_fkey";

ALTER TABLE "sample_requests"
  ADD CONSTRAINT "sample_requests_product_id_supplier_organization_id_fkey"
  FOREIGN KEY ("product_id", "supplier_organization_id")
  REFERENCES "catalog_products" ("id", "supplier_organization_id")
  ON DELETE RESTRICT ON UPDATE CASCADE;

The same change is applied to private_label_requests. Now the database checks the whole pair against the catalogue. In plain terms: the pair (P42, A) must exist as a row in the products table, and the row says P42 belongs to B, so the insert is rejected.

The pairing becomes a fact the database keeps rather than an invariant the application remembers.

In a LinkedIn post I called the column supplier_id to keep the example simple. The real column is supplier_organization_id, because suppliers are organizations in this schema.

The detail that is easy to get wrong: NULL

A request can name no product at all. In that case product_id is NULL, and the request should be valid.

PostgreSQL foreign keys default to MATCH SIMPLE: if any referencing column is NULL, the constraint is not checked. That is exactly what "this request names no product" should mean, so the default is what I want here. With MATCH FULL, a request with no product would also have to null out its supplier, which is wrong.

I mention it because the same rule cuts the other way. When a column must always be checked, MATCH SIMPLE plus a nullable column means a writer that forgets to fill it in switches the check off without any error. The same trap came up again on a different constraint, and the answer there was to make the column NOT NULL.

Keep the service check

I did not delete the application validation. The database is the backstop and the service is the user interface of the rule.

If the composite key rejects an insert, the driver surfaces a foreign-key error. The repository translates it:

// Simplified from the repository.
if (errorCode(error) === "P2003") {
  throw new DomainValidationError(
    "The linked product is not available for this supplier.",
  );
}

The message is deliberately vague. It does not confirm whether the product exists or who owns it. A buyer probing product ids should not be able to learn another supplier's catalogue from the difference between two error messages.

What this does not do

It would be easy to oversell this, so here are the limits:

It enforces one stored relationship: this product belongs to this supplier. It is not an authorization system and it is not tenant isolation. Something still has to decide who may create a request in the first place.
It does not fix a wrong row by changing the supplier. It rejects the pair.
It cannot see anything outside the columns it covers. A different table with a similar mismatch needs its own key.

How I would test it

A constraint that is never exercised is a comment. The test I want is at the database level, with direct inserts that skip the application entirely:

-- Illustrative test cases, not from the repository.
-- 1. Valid pair: product P42 owned by B, request names (P42, B)  -> accepted
-- 2. Wrong pair: product P42 owned by B, request names (P42, A)  -> rejected
-- 3. No product: request names (NULL, A)                         -> accepted

The three cases cover the intended path, the bug, and the NULL semantics. If all three behave, the rule lives in the schema and a future import script cannot bypass it by forgetting to call the service.

The same pattern, applied wider

The same mechanism shows up again in a later migration that makes a wrong-type tenant unrepresentable. Without it, the database would store a buyer organization as the owner of a catalogue product, or a supplier in the buyer slot of a request. Only whichever query remembered to filter on type would refuse it. The fix has three parts: a denormalised type column on the child row, a composite foreign key that forces it to agree with the organization row, and a CHECK that pins it to the one legal value for that slot.

The schema now has thirteen composite keys on organizations(id, type). A later design decision about marketplace accounts, which I describe in another article, refuses to disturb that network.

Two practical habits came out of that migration:

Count the violators first. Before adding the constraints, the migration counts existing rows that would break them and refuses to continue, naming the table and the number, rather than failing on a bare constraint name or silently changing data. A violation there is a real finding and gets reconciled by hand.
Mind the deploy order. The new columns are NOT NULL with no default, so every writer has to supply them before the migration runs. An older release cannot insert into those tables once the migration is applied.

The costs

Composite keys are not free:

The parent needs a unique constraint over the extra pair, and every referencing table carries a copy of the owning column.
Every writer must supply the extra columns, including seeds, scripts and old app versions.
ON UPDATE CASCADE means a change to the referenced column ripples down. That is intended, and it also means ownership changes need thought.
Error handling needs work, because a raw foreign-key violation is a poor message.

I accept those costs for rules where a silent wrong row is expensive and the data is shared across tenants.

A review you can run on your own schema

Look for tables that store a tenant or owner id next to a resource id. For each one, ask whether the database proves that the resource belongs to that tenant, or only proves that both exist. If it is the second, write down which code paths currently enforce the rule, and which could write around them: imports, repair scripts, admin tools, new services.

What I'd do differently

Add the composite key when the table is created. Retrofitting it took a separate migration that dropped and recreated the key. A new table can have it from the first commit.
Test at the database level from the start. I would write the three insert cases as part of the migration review.
Look for the pattern earlier. The same shape existed in other tables, and a wider migration followed two days later.
Say what the fix covers. It closes one gap. Calling it tenant isolation would be wrong.

Mohamed Elgohary, Mobile & Product Engineer, Cairo. mohamedelgohary.dev

Originally published on my site: mohamedelgohary.dev

Tested like a QA engineer: how I release mobile apps

Mohamed Elgohary — Tue, 10 Nov 2026 21:53:36 +0000

TL;DR

I have a QA/SDET background alongside my mobile engineering work, and I release apps the way a tester would: assume the happy path works and spend the effort on everything around it.
My public release checklist has 34 items in six sections: build, testing, backend, App Store, Google Play, and launch day. Store rules on it were checked against the official pages on 28 September 2026.
The habits that matter most: test the exact artifact you ship, refuse every permission, break the network on purpose, upgrade from the version people already have, and keep the API compatible with old installs.
A checklist is not a test suite. It tells you what to test and what evidence to keep.

Where this comes from

From August 2024 to August 2025 I worked as a Software Development Engineer in Test for TAKADOM AL-IRAQ (TTech), on a freelance basis. I was responsible for mobile, web and API testing on public-service products, and I built the Kotlin and Selenium automation for the Naftcom project, with API and regression coverage around its citizen and station workflows. That code is in a private repository, so I will not describe it in detail here.

I also build mobile apps. At Apps Square I am responsible for the mobile apps of several products, from setup and architecture through testing and delivery. At Inside Tech I built Bismar's customer and seller apps on Kotlin Multiplatform as the only mobile engineer on them, and both have public App Store and Google Play listings.

The testing habit comes with me. When I read a feature now, my first question is still what happens when this fails.

Test the thing you ship

A debug build proves very little about a release. The checklist is explicit that I test the signed release build with production settings, because code shrinking and release configuration can break things a debug build never shows.

A few items sit next to that one because they fail in the same quiet way:

Version and build number. Every upload needs a higher build number than the last (versionCode on Android, the build number on iOS), and the visible version must match the release notes.
Signing keys. Use Play App Signing so a lost upload key can be reset. Back up keys and passwords outside the repository.
Crash symbols. Upload the R8/ProGuard mapping file and the iOS dSYMs to the crash reporter. Without them, production stack traces are unreadable and the first real crash is a guessing game.
No debug leftovers. Check base URLs, feature flags, verbose logging of personal data and hidden test menus in the release configuration.

Devices and the upgrade path

The checklist asks for real devices at both ends: at least the oldest OS version you support and the newest, a small screen and a large one.

The upgrade test is the one I would least like to skip. Install the version on the store today, create some data, then update. Sessions, saved settings and local data must survive. A fresh install can be perfect while the person who has used the app for a year loses their session.

Failure paths first

This is where the QA background shows most. The checklist's network item reads: test slow, offline and flaky connections, confirm loading, retry and error states work, and make sure a repeated request never creates a duplicate order or payment.

That last clause is the important one. A retry that works is only half of the feature. The other half is that the retry is safe.

Here is a small example from a Flutter app I worked on, Fueler. The home screen loaded account, wallet and product data in parallel, and also resolved the user's location to find nearby stations. The original code waited for all of it before showing the page, so a slow location fix hid the wallet balance behind a loading state, even though the wallet never needed coordinates.

The test that guards the fix does what a tester would do: it delays one dependency on purpose.

// Simplified from the project's test file.
locationResolver.delay = const Duration(seconds: 3); // a genuinely cold fix
final loading = cubit.load();
await Future<void>.delayed(const Duration(milliseconds: 400));

// The screen is already usable before the location fix lands:
expect(cubit.state.status, HomeStatus.loaded);
expect(cubit.state.profile, _profile);
expect(cubit.state.products, _products);
// ...and the sections that need coordinates say so honestly:
expect(cubit.state.locationAccess, LocationAccess.unknown);
expect(cubit.state.stations, isEmpty);

A second test in the same group asserts that a warm fix emits exactly one state per refresh, so the stations section does not flash back to "locating". I did not measure device timing or any conversion effect, and I am not claiming one. The point is the shape of the test: slow down one thing, and check what the rest of the screen is allowed to do.

Permissions and the language you read in

Camera, location and notifications each need a test for the case people forget: the person taps Don't Allow. The app should keep working and explain why it needs the permission.

The checklist also treats Arabic as a test configuration, not a translation task: mirrored layouts, mixed Arabic and English text, and the system font size at its largest. Right-to-left bugs are easy to miss when you read the interface in only one language.

The API is part of the release

A mobile release is half a backend release, and the half people forget is the old app. People update slowly, so the checklist asks that the API keep serving the installed version: old endpoints and response shapes keep working, or a forced-update path ships first.

A minimum-supported-version check lets you retire a broken build without waiting for everyone to update. And on the data side: run migrations on a copy of production data first, and take a backup before the release.

I carry the same habit into my own tooling. PostSync Pro, an open-source Compose Desktop toolkit I built, sends REST requests, runs bounded assertions and validates responses against an OpenAPI specification. It is published as a beta, and the screens that still use simulated data are labelled as previews.

A regression pass on what hurts most

I do not try to retest everything. The checklist says to run a regression pass on the flows that matter most: sign-up, sign-in, checkout or booking, and anything a support call would be about. Notifications and deep links get their own check: they should open the right screen from a closed app, from the background and when signed out.

Store rules are test cases too

Both stores publish rules that read like requirements, so they become checks. A few from the checklist:

App Store: build with the required SDK (iOS 26 SDK or later, since 28 April 2026); keep App Privacy details in line with what the app and its SDKs collect; give App Review a working demo account and keep the backend on during review; offer account deletion inside the app; if you offer a third-party sign-in, offer an equivalent option such as Sign in with Apple; answer the encryption question in Info.plist.
Google Play: keep the Data safety form in line with the app; meet the target API requirement; provide sign-in details for review that keep working (reusable, no one-time code, not expiring); and for a new personal developer account, run the closed test before applying for production.

Dates and thresholds change, so the checklist links each rule to the official page and records when it was last checked. Re-check before you rely on any of it.

A store review is a separate gate with its own rules. It does not tell me whether checkout survives a flaky connection, so it never replaces my own testing.

Evidence, not memory

After a release I want to answer what was tested, on what, and what happened. A short record is enough. This is an illustrative template, not a file from a specific project:

release: 2.4.0 (build 118)
artifact: signed release build, production config
devices: [oldest supported OS, newest OS, small screen, large screen]
upgrade_from_live: passed, session and local data kept
network: slow / offline / flaky checked, repeated request created no duplicate
permissions: camera, location, notifications denied once each
arabic_rtl_large_text: checked
regression: sign-in, checkout, support-call flows
backend: old endpoints still served, min-version check in place
symbols: mapping file and dSYMs uploaded
rollout: staged, halt criteria agreed
owner_first_72h: named

Writing it down changes behaviour: a skipped line is visible, and "I thought we checked that" stops being an answer.

Launch day and after

The release is not over when the build is live. The last section of the checklist asks for:

release notes written for people, in every store language, saying what changed and whether they need to do anything;
someone who watches the first 72 hours, with an owner for crash reports, store reviews and support messages;
a plan for a bad release, since an installed update stays until you ship a fix: keep a hotfix path and server-side switches ready;
release analytics verified in production, firing once with the right values and respecting consent.

On Google Play the checklist also asks for a staged rollout: release to a small percentage first and halt if the crash or ANR rate rises. That applies to updates, not to a first release.

What I'd do differently

Turn more of the list into automated checks. Some items, like the upgrade path and the repeated-request test, are repeatable enough that a person should not have to remember them.
Attach an owner and evidence to each item. A checkbox says someone looked. It does not say what they saw.
Treat the list as a starting point. It is written for mobile apps with a backend. Some projects will skip items, and a project with payments will need more.
Keep the store rules fresh. They change, and the "reviewed on" date is only honest if someone updates it.
Be precise about what the list is. It is my public checklist, not a record that every item was done on every release.

Mohamed Elgohary, Mobile & Product Engineer, Cairo. mohamedelgohary.dev

Originally published on my site: mohamedelgohary.dev

One identity, many roles: what I got wrong about marketplace accounts

Mohamed Elgohary — Tue, 10 Nov 2026 21:52:52 +0000

TL;DR

I built EgyGomla, a B2B sourcing platform for Egyptian traders, with a separate email, account and password for each side of the market: buyers on one subdomain, suppliers on another.
A wholesaler buys from factories and sells to retailers. My "clean" design made the people the product is for pay the most.
The better model: the email is the person, and "buyer" and "supplier" are roles. In the data model that is one user with at most one buyer organization and one supplier organization, linked but never merged, with self-dealing blocked in the database.
This is a decided design (ADR-0013, status Accepted, 14 August 2026), and the migrations for it are written in the repo. It is not a claim that traders can do this in production today.

What I built first

EgyGomla helps Egyptian traders find manufacturers and suppliers, browse wholesale catalogues and request quotations. I built it end to end: web apps, dashboards, backend and Flutter apps. The public website is live; the mobile apps are not on the stores yet.

The production edge is one Caddy config, a hostname per surface:

egygomla.com: the public marketing site
app.egygomla.com: the buyer application
factory.egygomla.com: the supplier portal
admin.egygomla.com: the platform console
api.egygomla.com: the HTTP API
id.egygomla.com: Keycloak, the OIDC issuer

On top of that split I decided every role gets its own email. It felt tidy: each role in its own place, the data separate.

Where it breaks: the wholesaler

The product's own audience line names factories, importers, and wholesale and retail traders. A wholesaler, by definition of the trade, buys from the factory and sells to the retailer. That person is both sides of the market.

Under my first design, that trader needs a second email, a second account, a second password, and keeps switching between them. I was penalising my best users for being my best users.

The cost is not only friction. Two accounts share no catalogue, conversations, reviews or history, and the platform cannot know they are one business, which matters once you think about abuse.

What the big marketplaces do

On Amazon you buy on the main site, and Amazon's own seller registration guide says you can sell with the same email and password as your customer account. noon follows the same shape: you shop on its main site, and the seller portal is a separate surface on its own domain (login.noon.partners).

The pattern in both: one login, the buyer experience as the front door, selling as a second surface you opt into.

Identity is not a role

An email represents a person. "Buyer" and "supplier" are things that person does. Tie identity to role and anyone with more than one role pays for it, while everyone else never notices.

Where the constraint actually lived

I assumed the data model was the problem. OrganizationType is BUYER | SUPPLIER | PLATFORM, and a schema comment says one organization row cannot be both at once. But the enum was not what blocked wholesalers. Most of the multi-role machinery already existed:

Membership is many-to-many in practice, with a unique key on (userId, organizationId), so one person can belong to a buyer organization and a supplier organization at once.
An endpoint returns a list of the person's organizations, not one.
The guard resolves the acting organization on every request from a header, then checks the membership, its status, and that the organization's type matches the route.

What blocked the wholesaler was one rule in onboarding:

// onboarding service (paraphrased from the ADR)
if (onboarding.kind === "PROVISIONED") {
  throw new DomainValidationError(
    "This account already exists. Use an invitation to join another organization.",
  );
}

That rule was deliberate. An earlier decision used (issuer, subject) from the identity provider as the natural idempotency key for founding an organization, so "one founding per identity" was what that key bought, and the price was written down: no second organization through self-service.

So I did not have a type problem. I had a founding-rule problem, and knowing that spared me a much bigger change.

The design: one identity, two linked organizations

The decision keeps the enum as three mutually exclusive values and narrows the founding rule instead of deleting it: one self-service founding per identity per side. Illustrative SQL, simplified:

-- Illustrative. Simplified from the design, not the production schema.
ALTER TABLE organizations
  ADD CONSTRAINT organizations_one_founding_per_side
  UNIQUE (founder_user_id, type);

A person can found one buyer organization and one supplier organization; a second buyer organization is refused. The idempotency key stays natural and stays in the database, not in a header the client sends.

Link, not merge

I considered the obvious alternative: replace the type with capability flags like can_buy and can_sell. The ADR rejects it for two reasons.

First, thirteen composite foreign keys pin each party column to an organization of the right type, so a supplier can never sit in a buyer's slot. Flags mean rebuilding that network in one change. Second, a shortcut like a fourth BOTH type is worse: every CHECK turns into IN ('SUPPLIER','BOTH'), and the guarantee that one row is not both sides disappears without a constraint failing or a test going red.

So the two organizations stay separate rows joined by a declared link. Verification does not cross it: a verified badge belongs to the supplier organization, and reviews are testimony about the supplier, not something the buying side inherits.

Block self-dealing

Today an organization cannot invite itself as a supplier, because it is never both types. After that, a quote needs an invited recipient row, an award needs a quote, and a review is anchored to an award. The whole chain holds because the two types are disjoint on a single row.

Give one person a row on each side and the chain protects nothing: the buyer row invites the supplier row, awards it, and rates it five stars. The design has to re-derive that protection explicitly:

-- Illustrative. The shape of the constraint, not the exact production DDL.
-- Each row carries a denormalised copy of each party's link group,
-- held honest by a composite foreign key to organizations.
ALTER TABLE rfq_recipients
  ADD CONSTRAINT rfq_recipients_not_self_dealing
  CHECK (buyer_link_group_id <> supplier_link_group_id);

One detail changed between the sketch and the implementation. The sketch had a nullable link group with IS NULL branches. But a PostgreSQL foreign key is MATCH SIMPLE by default: if any referencing column is NULL, the constraint is satisfied without being checked. A writer that forgot the column would switch the rule off by omission, and nothing would report it. So an organization with no declared link is a group of one, its own id, and the check becomes a plain <> over two NOT NULL columns.

The design writes its limits down too:

Only a declared link is caught. Two organizations created with two emails and no declaration pass, as they do today.
Harvesting competitors' prices through your own legitimate request for quotation is market behaviour, not a schema problem. No key closes it, though the platform can at least see it once the link exists.

The link must never widen a read

Reads are scoped by the organization id the guard resolved from the membership. A supplier acting as a buyer is just a different buyer and gets the same not-found as anyone else. The link is presentational only: no query may use it to widen a tenant filter, and an architecture test fails the build if the column reaches a query condition, an ordering, an authorization path or a presenter.

Auth and sessions across subdomains

One identity across several hostnames sounds like it needs shared cookies. It does not.

Each hostname is its own origin. __Host- cookies carry no Domain attribute, so a session on one surface is never shared with another, even by accident.
Identity is shared through the issuer. Keycloak at id. is the OIDC issuer, and external identities are keyed by (issuer, subject), so the issuer's hostname is a data-model boundary, not branding.
Each application is an OIDC client with literal redirect and post-logout URLs. Wildcards are forbidden, so renaming a host is a two-place change, and the second place is the identity provider.
Application session material lives in Redis behind an opaque cookie.
The acting organization is chosen per request and verified against a membership. A header names it; the server decides whether the person may act as it. A client-sent "act as" role would be a worse design.

The cross-portal hop follows the usual OIDC pattern: the second application redirects to the issuer, the issuer already knows the person, and the person returns. I am describing that from the config and the ADRs, not from a recorded test. The design also calls for an explicit link between the buyer app and the supplier portal, with no silent switching, and every screen that changes something names the acting organization and its side.

If you already have duplicate accounts

I have not run a merge of duplicate accounts in EgyGomla, and nothing here claims that. This is general guidance.

Count before you change anything. The migrations in this repo count rows that violate a new rule and refuse to continue, naming them, instead of coercing or deleting them. Do the same for duplicates, using signals you trust: normalised email, phone, tax id, company name.
Never auto-merge on a match. Similar details do not prove the same person, and a merge is hard to undo.
Let the person confirm both. Ask them to sign in to each account, then attach both organizations to one identity and link them. Do not collapse them into one row.
Keep catalogues and history where they are. The link is for understanding, not for combining data.
Expand, backfill, contract. Add nullable columns, backfill, then add constraints, and build unique indexes concurrently on a live database.
Ship writers first. If a new column is NOT NULL with no default, every writer, including seeds and scripts, must supply it before the migration runs.
Expect a tail. Some people will never link. They behave as they do today, which is acceptable if the limit is written down.

What I'd do differently

Start from the heaviest user's day. Ask who the person is before deciding what each page needs, and walk through a day for the user who touches both sides.
Find where the constraint lives first. I blamed the enum; the blocker was an onboarding rule I had chosen on purpose.
Write the abuse chain before the happy path. The review system leaned on a property no constraint stated. Making it explicit was the most important part of the design.
Do not ship the second-organization path alone. The ADR says it must not go out without the anti-self-dealing constraints, or self-dealing drops from "needs a second email" to "one click".
Keep marketing behind the feature. The ADR forbids copy like "one account buys and sells" until the feature exists, and a copy test guards the site's other promises.
Say what is decided and what is shipped. This article describes a decision, not something in front of traders.

Mohamed Elgohary, Mobile & Product Engineer, Cairo. mohamedelgohary.dev

Originally published on my site: mohamedelgohary.dev