The requester doesn't want to know which request succeeded, because they are duplicates and one is a retry!
When you are using TCP, and you send the same data twice because of a delayed ack, you likewise don't care if the ACK is for the first time or the second time you sent the data. You just know the other side got the data, and that's all you care about.
Your database should not allow both commits to happen - one should get rolled back.
If it processed 99% of the request and the final bookkeeping failed because of a duplicate, that's still a failed request.
Arguably this should be the primary way you check for idempotent requests - you shouldn't have a separate check for existence, you should have the insert/update fail atomically.
This is the same thing you see on filesystems for TOCTOU security holes - the right way is to atomically access and modify once, and you only know the request was already processed because that fails.
Not in the payments world. If you’re 99% done but only the bookkeeping failed, then it’s likely that money is changing hands and you need to deal with that fact. Payments are not an atomic infrastructure and you cannot magic that into reality.
Payments are multistep but each of the steps needs to be atomic. The "create payment" operation must be transactional and the communication channel between you and the processor must be idempotent so you don't inadvertently create multiple payments.
The fact that payments have a settlement process is not relevant to this discussion.
> The "create payment" operation must be transactional and the communication channel between you and the processor must be idempotent so you don't inadvertently create multiple payments.
Yes, I agree. You want to generate a token, persist it locally and use that to communicate with the payment gateway, so re-submissions use the same key and either error or return the transaction state.
> The fact that payments have a settlement process is not relevant to this discussion.
I wasn't talking about settlement, I was talking about the processing aspect. What I meant was: once you kickstart the process with the gateway, money is highly likely to change hands as a result. This means a process of:
1. POST /checkout
2. Create token
3. POST to payment gateway with token
4. Wait for gateway to return
5. Persist transaction/error
6. Return success/error
What is needed is to persist and return the token to the caller before contacting the payment gateway, to make a check + retry mechanism possible.
And yes, I've seen code that follows steps 1-6 exactly as I've described and, yes, all the problems you imagine would occur from those steps have occurred at one time or another.
This is one possible API but it's not the dominant way payments are exposed by payments providers. Stripe, Amazon, Paypal, et al do this differently. They're fine.
I pointed to Braintree in another comment where this is very much not fine. Also these providers operate at a lower level of the stack than we do, so they have finer control over the process than you or I.
Even then, it’s not fine because those requests might time out, or your request times out waiting for theirs. Just because your provider abstracts behind one API doesn’t mean you necessarily can!
And if there is part of the process that isn't idempotent, you want to make that surface area as small as possible, so that only failures at that one discrete step can cause issues.
Fsync on PLP drives isn't strictly a NOP - you still take a latency hit from the round trip of the command to the NVMe device, where it is implemented as a NOP.
Minor nit, but ECG and EKG are synonyms - the K is used because it is less likely to be confused verbally or in a written order... perhaps you mean EEG?
You know what, you're almost certainly right. One was a check to make sure my heart was ok, and the other one was a check to make sure my brain was ok.
FDI itself is not enough. Modern national champions happen because state protectionism, typically under autocratic industrial policy (Asian Tigers), in combination with FDI. Hyundai was suppose to be Honda, you can throw TSMC in there. There's no sign Poland is going to get national class to world class champions, because democracies more easily captured and EU forbids tier of subsidies and protectionism that enable giants that compete with established incumbents. Is there any strategic Polish company on road to being world class?
On paper countries can build giants without FDI, but can't build giants without industrial policy Poland can't adopt due to EU trap (which basically designed to keep west euro industrial incumbents on top) and (IMO) if Poland ever tries, FDI tap going to stop. Structurally Poland is periphery not core, allowed to prosper but not overtake, which puts ceiling. Exception being defense, but even then stepping on west euro toes.
If there is such a ceiling (clearly, I doubt it, seeing many of the main German industry leaders going down or offshore, so there is plenty space to grow), it is not of the EU's doing. It it about money and the advantages large incumbents have in our version of market capitalism.
DE still collects checks from global champions offshoring. Offshoring "fine" as long as money flows back to HQ. Allowing peripheral competitors to take your rent on the other hand less fine. The ceiling is EU's doing - it's EU legislation which does not allow member states to adopt the tier of subsidies/industrial policies to build competitors that can rival EU incumbents. Which can lose out to competitors with greater leverage (i.e. US), but unlikely to Poland. Of course cannot say it's impossible, but we have not seen case in modern economic history where global strategic champions arise without massive subsidies/protectionism, the type EU blocks within bloc to lock in existing hierarchy.
Small, but exemplary, and given the context of the post and arguments, developing exemplary leading companies is a sign that Poland is developing a deep base beyond mere outsourcing, even if there are a small number and they're not huge yet.
It's like comparing a 6-year-old soccer player to Lionel Messi - you're looking at early signs of development, and the progress to getting there, not saying Poland is already there, but there are positive signs it is on that path.
Yeah, in general, this is a problem that people have spent a lot of time thinking about; while floating-point numbers can be finicky, they're what you have to work with if you have inputs at multiple scales.
(Meanwhile, I wonder why it's a fair bit harder to look up Ozaki et al.'s optimized version [0] compared to Shewchuk's original paper [1], unless perhaps later authors have found it to be no improvement at all.)
his predicates paper opens with "Computational geometers despise floating-point arithmetic" same trick as the CG title: write the sentence a frustrated reader would write, then aren it.. if you like those the Triangle paper is the third one in the same key
I keep getting surprised that people who are all-in on this (" i regular execute tasks that require hundreds of subagents ") don't have any idea of what is happening even a single layer below their interface to the LLM ("in practice the context window is effectively unlimited or at least exceptionally high — 100m+ tokens.")
I looked at that response by GP (rgbrenner) and refrained from replying because if someone is both running hundreds of agents at a time AND oblivious to what "context window" means, there is no possible sane discourse that would result from any engagement.
ok "series of context windows spread across many agents".. sure much clearer.
Doesn't change my point: the amount of code the agent can operate on is very large, if not unlimited, as long as you put even a little bit of thought into structuring things so it can be divided along a boundary.
If you let the codebase degrade into spaghetti, then the LLM is going to have the same problem any engineer would have with that. The rules for good code didn't disappear.
Context windows don't necessarily cleanly divide. Getting each agent to be able to task within a context window is a hard problem.
It's like like if your context window with one agent is n, your context window with 10 agents is n/10. It is some skill, but that is also where a lot of the advances are coming in.
300k tokens--the useable context window of a single agent--is about 40k lines of code and you can't figure out a natural breakpoint within that code to divide up the task?
When you are using TCP, and you send the same data twice because of a delayed ack, you likewise don't care if the ACK is for the first time or the second time you sent the data. You just know the other side got the data, and that's all you care about.
reply