<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd" -->

---
title: Could gen_tcp / ssl expose whether a failed send...
description: A forum post proposes exposing whether a failed gen_tcp or ssl send actually transmitted data before failing. Currently {error, closed} gives no information...
canonical: https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Could gen_tcp / ssl expose whether a failed send submitted any data? | daily.dev
og:description: A forum post proposes exposing whether a failed gen_tcp or ssl send actually transmitted data before failing. Currently {error, closed} gives no information...
og:url: https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd
og:image: https://api.daily.dev/og/posts/MNKKPGqmD.png
og:image:alt: Could gen_tcp / ssl expose whether a failed send submitted any data?
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Could gen_tcp / ssl expose whether a failed send submitted any data?

**[Erlang Forums](https://daily.dev/sources/erlangforums)** · 4 min read · 0 upvotes · 0 comments

## Summary

A forum post proposes exposing whether a failed gen_tcp or ssl send actually transmitted data before failing. Currently {error, closed} gives no information about whether the request reached the server, making retries risky for non-idempotent operations like POST. The author traces OTP internals showing it sometimes knows a send failed before submission but discards that detail, and proposes a send_with_status/2 function returning not_submitted or unknown. In a prototype test of 500 POST requests, 102 failures were classified as not_submitted and retried, 32 stayed ambiguous, and zero duplicate executions occurred on the server.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://erlangforums.com/t/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data/6096>

## Questions this post answers

### Why does Erlang's gen_tcp return {error, closed} with no way to know if data was already sent?

Erlang's gen_tcp and ssl modules internally sometimes know whether a send failed before any data was submitted to the transport, but this information is discarded before reaching the caller. The traditional inet backend can fail during socket lookup before calling the backend send, and prim_inet:send/4 distinguishes between port_command/3 rejecting versus accepting then failing, yet both cases surface only {error, Reason}.

_Developers debugging flaky retry logic in Erlang HTTP clients can follow OTP proposal discussions like this on daily.dev._

### Is it safe to retry a POST request after getting {error, closed} from an Erlang TCP connection?

Not reliably without more information, since {error, closed} does not indicate whether the request data was already sent to the server. In Tesla issue #467, a developer reported duplicate requests after adding retries for socket-closed errors. A proposed OTP API using a not_submitted versus unknown status, tested against 500 POST requests, safely retried 102 failures classified as not_submitted with zero duplicate executions observed.

_Teams building retry logic around idempotency concerns can track proposals like this one on daily.dev._

## Similar posts on daily.dev

- [The Case of the Readable Dead Connection: A Ruby Mystery](https://daily.dev/posts/the-case-of-the-readable-dead-connection-a-ruby-mystery-smy8cygd3) · RUBYLAND · 3 upvotes · 1 comments
- [The occasional \`ECONNRESET\` \(part 1](https://daily.dev/posts/the-occasional-econnreset-part-1-hutyerwoz) · Hacker News · 0 upvotes · 0 comments
- [Erlang socket layer throughput improvements](https://daily.dev/posts/erlang-socket-layer-throughput-improvements-k54xnpxbv) · Erlang Forums · 0 upvotes · 0 comments
- [Post Mortem: HTTP Request Smuggling Vulnerability](https://daily.dev/posts/post-mortem-http-request-smuggling-vulnerability-36fsdzezd) · Crystal · 7 upvotes · 0 comments
- [How to Deal With Errors and Failures in LLM-Powered Applications](https://daily.dev/posts/how-to-deal-with-errors-and-failures-in-llm-powered-applications-0uawtim2f) · ByteByteGo · 5 upvotes · 0 comments

---

Tags: [#erlang](https://daily.dev/tags/erlang)

[View this post on daily.dev](https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Could gen_tcp / ssl expose whether a failed send submitted any data?","url":"https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd"},"datePublished":"2026-10-30T18:14:54.997Z","dateModified":"2026-10-30T18:15:24.598Z","description":"A forum post proposes exposing whether a failed gen_tcp or ssl send actually transmitted data before failing. Currently {error, closed} gives no information...","image":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","thumbnailUrl":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","isAccessibleForFree":true,"articleSection":"Erlang Forums","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Erlang Forums","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/b352c25bf0ad4af3b186d4cdf1c4f17c","url":"https://daily.dev/sources/erlangforums"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"erlang","timeRequired":"PT4M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Erlang Forums","item":"https://daily.dev/sources/erlangforums"},{"@type":"ListItem","position":3,"name":"Could gen_tcp / ssl expose whether a failed send submitted any data?"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/could-gen-tcp-ssl-expose-whether-a-failed-send-submitted-any-data--mnkkpgqmd#faq","mainEntity":[{"@type":"Question","name":"Why does Erlang's gen_tcp return {error, closed} with no way to know if data was already sent?","acceptedAnswer":{"@type":"Answer","text":"Erlang's gen_tcp and ssl modules internally sometimes know whether a send failed before any data was submitted to the transport, but this information is discarded before reaching the caller. The traditional inet backend can fail during socket lookup before calling the backend send, and prim_inet:send/4 distinguishes between port_command/3 rejecting versus accepting then failing, yet both cases surface only {error, Reason}. Developers debugging flaky retry logic in Erlang HTTP clients can follow OTP proposal discussions like this on daily.dev."}},{"@type":"Question","name":"Is it safe to retry a POST request after getting {error, closed} from an Erlang TCP connection?","acceptedAnswer":{"@type":"Answer","text":"Not reliably without more information, since {error, closed} does not indicate whether the request data was already sent to the server. In Tesla issue #467, a developer reported duplicate requests after adding retries for socket-closed errors. A proposed OTP API using a not_submitted versus unknown status, tested against 500 POST requests, safely retried 102 failures classified as not_submitted with zero duplicate executions observed. Teams building retry logic around idempotency concerns can track proposals like this one on daily.dev."}}]}
```

