DEV Community: mohammad rostami

Reliable Form Submissions: Dirty State, Fingerprints, and Idempotency

mohammad rostami — Fri, 21 Aug 2026 07:07:30 +0000

A disabled Submit button protects the UI. It does not protect the data.

It is tempting to treat this as enough protection against duplicate submissions:

<button type="submit" disabled={isSubmitting}>
  Submit
</button>

The button is worth disabling. It gives the user immediate feedback and prevents an obvious second click. But it only controls one interaction in one browser tab.

It cannot tell us whether a request was retried by the client, whether two requests crossed the network at nearly the same time, or whether the server completed a write before the response disappeared.

Consider a small order form:

type OrderFormValues = {
  firstName: string;
  lastName: string;
  amount: number;
  price: number;
};

A straightforward submission might look like this:

await fetch("/api/orders", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(values),
});

Now imagine that the server creates the order, but the response never reaches the browser. The UI sees a network error. The user tries again. Without any other protection, the second request can create a second order.

The difficult part is not the second click. The difficult part is deciding whether the second request represents a new operation or a retry of the first one.

The mental model I use separates two identities:

A fingerprint identifies the content of the request.
An idempotency key identifies the operation the user intended to perform.

They solve different problems, and neither is a replacement for the other.

Content identity starts with normalization

Two form values can be different in JavaScript while representing the same business input.

These names are not byte-for-byte equal:

"Sara"
" Sara "

But if the application trims names before saving them, that whitespace is not a meaningful change. The same issue appears with values such as "150" and 150, or 150 and 150.0.

I prefer to make those rules explicit before creating a fingerprint:

function normalizeOrder(values: OrderFormValues) {
  return {
    firstName: values.firstName.trim(),
    lastName: values.lastName.trim(),
    amount: Number(values.amount),
    priceInCents: Math.round(Number(values.price) * 100),
  };
}

function canonicalizeOrder(values: OrderFormValues): string {
  return JSON.stringify(normalizeOrder(values));
}

Converting the price to cents is part of the example's business normalization. It avoids using small floating-point differences as evidence that two prices are different.

For local comparisons, the canonical string is already a useful fingerprint:

const fingerprint = canonicalizeOrder(values);

For storage or comparison across system boundaries, I would usually hash that canonical value:

async function createOrderFingerprint(
  values: OrderFormValues,
): Promise<string> {
  const payload = canonicalizeOrder(values);
  const bytes = new TextEncoder().encode(payload);
  const digest = await crypto.subtle.digest("SHA-256", bytes);

  return Array.from(new Uint8Array(digest), (byte) =>
    byte.toString(16).padStart(2, "0"),
  ).join("");
}

The normalization rules must come from the domain. If array order has no business meaning, sort the array before hashing it. If order is meaningful, sorting it would create the wrong identity. A fingerprint is only as correct as the canonical representation behind it.

Dirty state is also a domain question

Form libraries usually expose an isDirty flag. That flag is useful, but it normally compares raw form values with the original defaults. It does not know which differences matter to the business.

A business-aware check can compare the initial and current fingerprints instead:

const initialFingerprint = canonicalizeOrder(initialValues);
const currentFingerprint = canonicalizeOrder(currentValues);

const isMeaningfullyDirty =
  currentFingerprint !== initialFingerprint;

If the user changes "Sara" to " Sara ", the raw form may be dirty while isMeaningfullyDirty remains false.

If the user changes amount from 2 to 3, the fingerprint changes. If they change it back to 2, the fingerprints match again and the form is no longer meaningfully dirty.

This is also why UI-only state should stay out of the fingerprint. A search query, an expanded panel, or the selected tab may change the component state without changing the order that will be sent to the server.

For example, customerSearch does not belong in the normalized payload:

type OrderPageState = OrderFormValues & {
  customerSearch: string;
};

function normalizeOrderPage(values: OrderPageState) {
  return normalizeOrder(values);
}

Using the same canonicalization rules for Dirty State and submission gives both features the same definition of a meaningful change.

Operation identity belongs to the idempotency key

A fingerprint tells us that two payloads contain the same business data. It does not tell us whether the user intended one operation or two.

A user may intentionally create two identical orders. Those orders have the same fingerprint, but they are still separate operations. This is why I would not derive the idempotency key from the fingerprint:

// Incorrect: identical payloads can still be separate operations.
const idempotencyKey = fingerprint;

Instead, the client creates a random key for a new operation and reuses it only when retrying that operation with the same fingerprint.

type PendingOperation = {
  fingerprint: string;
  idempotencyKey: string;
};

let pendingOperation: PendingOperation | null = null;

async function submitOrder(values: OrderFormValues) {
  const fingerprint = canonicalizeOrder(values);

  const operation =
    pendingOperation?.fingerprint === fingerprint
      ? pendingOperation
      : {
          fingerprint,
          idempotencyKey: crypto.randomUUID(),
        };

  pendingOperation = operation;

  const response = await fetch("/api/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Idempotency-Key": operation.idempotencyKey,
    },
    body: JSON.stringify(values),
  });

  if (!response.ok) {
    throw new Error("Order submission failed");
  }

  const result = await response.json();

  // A later submission now represents a new operation,
  // even if the user enters the same values again.
  pendingOperation = null;

  return result;
}

There are two deliberate choices in this code.

First, a failed attempt does not immediately discard the key. Retrying the same payload should reuse the identity of the pending operation.

Second, a successful response clears that identity. If the user intentionally submits the same values again later, the client generates a new key and the server is allowed to create another order.

Disabling the button still makes sense, but the key is what allows the server to recognize a repeated operation.

The server has to bind the key to the payload

The client can help manage operation identity, but the guarantee must exist on the server.

For each idempotency key, the server needs to store at least:

type IdempotencyRecord = {
  key: string;
  fingerprint: string;
  status: "processing" | "succeeded";
  response?: {
    orderId: string;
  };
};

The server should calculate the fingerprint itself. Trusting a fingerprint supplied by the browser would allow a modified client to claim that two different payloads are identical.

The key also has to be claimed atomically. A separate find() followed by insert() leaves a race in which two requests can both observe that the key is missing.

The storage API can expose that atomic decision directly:

type ClaimResult =
  | { kind: "new" }
  | { kind: "mismatch" }
  | { kind: "processing" }
  | {
      kind: "completed";
      response: { orderId: string };
    };

async function createOrder(request: Request) {
  const key = request.headers.get("Idempotency-Key");

  if (!key) {
    return new Response("Idempotency key is required", { status: 400 });
  }

  const values = (await request.json()) as OrderFormValues;
  const fingerprint = await createOrderFingerprint(values);

  const claim: ClaimResult = await idempotencyStore.claim({
    key,
    fingerprint,
  });

  if (claim.kind === "mismatch") {
    return new Response("Key reused with a different payload", {
      status: 422,
    });
  }

  if (claim.kind === "completed") {
    return Response.json(claim.response);
  }

  if (claim.kind === "processing") {
    return new Response("Operation is already processing", {
      status: 202,
    });
  }

  const order = await orderRepository.create(normalizeOrder(values));
  const response = { orderId: order.id };

  await idempotencyStore.complete({ key, response });

  return Response.json(response, { status: 201 });
}

In a relational database, a unique constraint on the key is the minimum protection against concurrent claims:

CREATE UNIQUE INDEX idempotency_key_unique
ON idempotency_records (key);

The exact persistence model depends on the operation, but the invariant should remain the same:

The same key and the same fingerprint refer to the same operation.
The same key with a different fingerprint is rejected.
A new key represents a new operation, even when its fingerprint matches an older one.

The mistakes I would avoid

The first mistake is treating isSubmitting as a data-integrity mechanism. It is UI state, and it cannot protect the server from concurrent or repeated requests.

The second is using a fingerprint as the idempotency key. That incorrectly merges separate operations that happen to have identical payloads.

The third is hashing raw form state. Whitespace, numeric representation, property order, or UI-only fields can create different hashes for the same business input. Canonicalization has to happen before hashing.

The final mistake is implementing the guarantee only in the browser. The browser can choose and reuse a key, but only durable, atomic server-side storage can enforce it.

The compact version of the model is:

Dirty State compares the current content with the initial content.

A fingerprint identifies that content.

An idempotency key identifies the operation performed with it.

Once those responsibilities are separate, the Submit button can remain what it should be: a useful interaction detail, not the last line of defense against duplicate writes.

Why Your Zod Validation Fails Before It Even Runs (And How to Fix It)

mohammad rostami — Thu, 11 Jun 2026 08:43:43 +0000

If you're using Zod with react-hook-form, you've probably seen this at least once:

Invalid input: expected number, received NaN

At first glance, it looks like a simple validation issue.
It’s not.

The real problem

When working with form inputs:

All values come in as strings
z.coerce.number() tries to convert them
Empty input ("") or invalid values → NaN

And here’s the catch:
Zod fails before your .min() / .max() validations run.

So instead of your custom message, you get a generic (and not very helpful) error.

It gets trickier

If you're using TypeScript:

z.input<typeof schema> ≠ z.output<typeof schema>
react-hook-form works with the input type
Zod gives you the output type after parsing

This mismatch can lead to confusing type errors and wrong assumptions about your data.

The fix

You need to handle invalid input before Zod tries to validate it:

readTime: z.preprocess((val) => {
  if (val === "" || val === undefined) return undefined;

  const num = Number(val);
  return isNaN(num) ? undefined : num;
},
z.number()
  .min(2, 'Minimum read time is 2 minutes')
  .max(60, 'Maximum read time is 60 minutes')
)

What this solves

Empty input → handled properly
Invalid numbers → no more NaN issues
Custom validation messages → actually shown
Cleaner UX overall

Takeaway

If you're using z.coerce.number() in forms, don't rely on it blindly.
Always normalize your input first.

Because sometimes the bug isn't in your validation rules…
it's in how your data arrives before validation even starts.

Technical Deep Dive: How React Server Components Work and Where the Vulnerabilities Appear

mohammad rostami — Mon, 15 Dec 2025 20:42:52 +0000

Hi everyone
In a recent, I examined CVE-2025-55182, a critical vulnerability in React Server Components caused by an unsafe deserialization path that could lead to unauthenticated remote code execution. That issue highlighted how deeply framework internals can influence the security posture of applications built on top of them.

Shortly after that disclosure, an additional set of security vulnerabilities was published affecting the same architectural layer in React Server Components (RSC) and Next.js. While these issues do not result in immediate remote code execution, they introduce significant risks, including Denial of Service (DoS) and unintended exposure of server-side source code and internal implementation details under specific conditions.

This article builds on that context and focuses on the underlying execution model of React Server Components, explaining how these issues emerge at the framework level and why they matter for production deployments.

To understand why the recently disclosed issues in React Server Components (RSC) lead to Denial of Service and source code exposure, it helps to look at how the RSC execution pipeline actually works on the server.

React Server Components: Server-Side Execution Flow

A simplified but accurate RSC request lifecycle looks like this:

1 - Incoming request reaches the RSC endpoint

In Next.js, this typically maps to an internal route such as /_rsc
The request is processed before authentication and before application middleware

2 - Request body parsing and protocol decoding

The payload is parsed according to the React Flight protocol
This includes decoding serialized component references, props, and execution hints
At this stage, React assumes the payload shape is valid enough to be processed

3 - Component graph reconstruction

React reconstructs the Server Component tree from the serialized input
Module references are resolved and loaded
Async boundaries and Suspense segments are registered

4 - Server rendering and streaming

Components are executed on the server
Output is serialized again and streamed back to the client in chunks
Error boundaries and partial results are flushed incrementally

5 - Error and recovery

If an exception occurs mid-stream, React attempts to recover gracefully
Metadata, stack traces, and module identifiers are still available internally
Each of these phases is sensitive to malformed or adversarial input.

How Denial of Service Is Triggered

The DoS issue arises primarily in steps 2 and 3, before any application logic is involved.
A malicious request can:

Inflate the serialized payload size
Introduce deeply nested or cyclic references
Force excessive async boundary resolution

Conceptual example:

POST /_rsc
Content-Type: application/json

{
  "type": "ServerComponent",
  "props": {
    "children": {
      "children": {
        "children": {
          ...
        }
      }
    }
  }
}

Even if the payload is syntactically valid, React will:

Attempt to deserialize it
Build an in-memory component graph
Schedule execution and streaming work

This leads to:

High CPU usage during decoding
Memory pressure during graph reconstruction
Worker or event-loop saturation

Crucially, this happens without hitting user-defined code and without authentication.

This makes traditional defensive assumptions at the application layer largely ineffective.

How Source Code Exposure Can Occur

Source code exposure is a side effect of how React handles errors during steps 4 and 5.
When a rendering or serialization error occurs mid-stream:

React still holds references to internal module paths
Stack traces include resolved file locations
Component metadata is partially serialized

In certain edge cases, this information may:

Leak into the streamed response
Appear in error payloads
Be flushed before the stream is properly aborted

Example of leaked information:

Error: Failed to resolve Server Component
  at /app/src/components/admin/UserList.server.tsx
  at react-server-dom-webpack/server

This reveals:

Project directory structure
Server-only component boundaries
Internal module layout and naming

While not a standalone exploit, this materially reduces the effort required for targeted attacks.

Why Server Actions Are Not Required

A common misconception is that these risks only apply when using Server Actions.
In reality:

Server Actions are an API surface
RSC is a runtime and protocol

Even a simple page like:

export default async function Page() {
  return <Dashboard />;
}

Still triggers:

Request deserialization
Component graph reconstruction
Server execution and streaming

The vulnerable logic executes regardless of whether Server Actions are defined.

Key Takeaways

React Server Components introduce a fundamentally new server-side execution model that combines request deserialization, component graph reconstruction, and streaming-based rendering into a single framework-managed pipeline.
As a result, the effective attack surface exists before authentication, before application middleware, and before any user-defined business logic is executed.
Malformed or adversarial RSC requests can lead to:
Denial of Service, through excessive CPU usage, memory pressure, and worker or event-loop saturation during deserialization and component graph reconstruction
Accidental disclosure of server-side implementation details, including internal file paths, component boundaries, and module layout, as a side effect of streaming error handling
These issues are not caused by misconfigured applications or unsafe user code. They are framework-level vulnerabilities in the React Server Components runtime itself and cannot be mitigated reliably through application-layer defenses alone.

Official advisories and patches

Denial of Service and Source Code Exposure in React Server Components

Next.js security update

A Deep Dive into Nested ScrollView Behavior in React Native: Root Causes and Practical Solutions

mohammad rostami — Mon, 24 Nov 2025 21:24:08 +0000

Hi everyone

During the development of a recent screen in one of our applications, I faced a scenario where a section of the content needed to scroll independently, while the entire page itself was wrapped inside a parent ScrollView. At first glance, this seems like a straightforward layout. In practice, however, the behavior of nested scroll containers became unexpectedly challenging, especially when tested across platforms.

Observed Behavior Across Platforms

On iOS, the internal ScrollView generally behaves as expected without requiring additional configuration.

On Android, the situation is different. The inner scroll often fails to activate, gets interrupted by the outer scroll, or reacts inconsistently. This occurred not only on lower-end devices but on high-end models as well.

The issue becomes even more noticeable when:

The two scroll layers have different directions (for example, vertical parent and horizontal child)
The inner content has dynamic height or width
Multiple simultaneous gestures are triggered during rapid scrolling

It quickly became clear that this was not simply a styling conflict, but a deeper issue related to gesture priority and event handling at the platform level.

Root Cause Analysis: What Actually Happens Behind the Scenes

After reviewing React Native’s gesture responder system and native scroll behavior in both iOS and Android, several key points emerged:

On Android, the parent ScrollView receives gesture priority by default
It attempts to determine whether the gesture belongs to itself before allowing the child ScrollView to respond. This decision is not always accurate, which often prevents the inner scroll from initiating.
On iOS, gesture separation is more precise
The system determines the appropriate scroll target early and allows both parent and child scroll views to operate smoothly.
Mixed-direction scrolling increases complexity
When the parent scrolls vertically and the child scrolls horizontally, the system must re-evaluate gesture direction multiple times. On Android, this frequently results in jumps, unexpected direction changes, or the parent taking control prematurely.
Dynamic layout measurement affects gesture routing

Incorrect or late size calculations can cause the inner ScrollView to lose gesture ownership too early.

Practical Solutions Based on Testing

Several solutions helped achieve consistent, reliable behavior for nested scrolling:

Enable nestedScrollEnabled on the inner ScrollView (Android)

<ScrollView>

     <ScrollView nestedScrollEnabled>

        {/* content */}

     </ScrollView>

</ScrollView>

This is the foundational setting required to ensure the child scroll can properly receive gestures.

Use flexGrow for proper content measurement

contentContainerStyle={{ flexGrow: 1 }}

This ensures the inner ScrollView’s content is measured correctly, reducing gesture conflicts with the parent view.

Handle mixed-direction scrolling intentionally

When the parent and child scroll in different directions, it is often beneficial to temporarily enable or disable one of the scroll containers based on the detected gesture direction.

This approach helps the system correctly determine which layer should receive the gesture and prevents unintended handoffs during scroll.

Complete Example

// https://www.linkedin.com/in/mohammadrostami/
import React from 'react';
import { ScrollView, View, Text, StyleSheet } from 'react-native';

export default function NestedScrollExample() {
  return (
    <ScrollView style={styles.parentScroll}>
      <View style={styles.container}>

        <Text style={styles.title}>Parent ScrollView</Text>

        <ScrollView
          nestedScrollEnabled
          style={styles.childScroll}
          contentContainerStyle={{ flexGrow: 1 }}
        >
          <View style={styles.childContent}>
            {Array.from({ length: 25 }).map((_, i) => (
              <Text style={styles.item} key={i}>
                Child Item {i + 1}
              </Text>
            ))}
          </View>
        </ScrollView>

        <View style={styles.footer}>
          <Text style={styles.footerText}>Footer Content</Text>
        </View>

      </View>
    </ScrollView>
  );
}

const styles = StyleSheet.create({
  parentScroll: {
    flex: 1,
    backgroundColor: '#fafafa',
  },
  container: {
    padding: 16,
  },
  title: {
    fontSize: 18,
    marginBottom: 12,
  },
  childScroll: {
    height: 250,
    borderRadius: 8,
    borderWidth: 1,
    borderColor: '#ccc',
  },
  childContent: {
    padding: 12,
  },
  item: {
    paddingVertical: 10,
    fontSize: 16,
  },
  footer: {
    marginTop: 30,
    padding: 12,
    backgroundColor: '#eee',
    borderRadius: 8,
  },
  footerText: {
    fontSize: 16,
  },
});

Conclusion

Nested ScrollViews introduce a set of platform-specific challenges in React Native, particularly in Android where gesture routing differs significantly from iOS. Understanding how gestures are prioritized, how mixed-direction scrolling is handled, and how layout measurement affects scroll behavior is essential for creating smooth, predictable user experiences.
Properly configuring nestedScrollEnabled, managing dynamic content sizing, and intentionally controlling scroll interactions are key to resolving these issues in production-grade applications.