[HN Gopher] This Message Does Not Exist
___________________________________________________________________
This Message Does Not Exist
Author : sebtron
Score : 286 points
Date : 2024-05-31 14:43 UTC (1 days ago)
(HTM) web link (www.kmjn.org)
(TXT) w3m dump (www.kmjn.org)
| fifteen1506 wrote:
| Open in Thunderbird, it will be there, probably.
|
| I had a similar, though not the same, on new and old Outlook and
| indeed it appeared on Thunderbird. After an hour or two also
| appeared on Outlooks.
| playingalong wrote:
| The commentary is golden.
|
| Trying to guess what is going on. I guess they refer to the
| original message (on the server) and its local copy. Both
| referred to as "the message".
| wild_pointer wrote:
| I asked ChatGPT, it assumed the same
|
| > The message you were working on does not exist anymore in the
| server's storage, which is why you can't save it. Copying the
| content before discarding ensures you don't lose your work and
| can paste it into a new draft.
| ileonichwiesz wrote:
| That's just paraphrasing
| klysm wrote:
| This is the most Microsoft error message I have ever seen
| fragmede wrote:
| This message will delete itself after this. Please save its
| contents if you with to retain it.
| m463 wrote:
| Wouldn't a more microsoft message be about competing products
| failing to exist?
|
| I've seen teams messages on firefox and safari about features
| not existing "download the teams native app!"
| soulofmischief wrote:
| Excellent reflection on an absurd premise, thanks for sharing.
| thwarted wrote:
| I've had similar philosophical thoughts about a transaction
| rollback.
|
| Consider this definition from go's database/sql package.
| func (tx *Tx) Rollback() error
|
| Rollback can fail, indicated as such by it can return an error.
| What are the cases where rollback could fail and what's the
| recovery mechanism? Does a failed rollback mean (logically) that
| the transaction is still open and uncommitted? But really,
| invoking rollback can never fail to abort the transaction, so the
| error result has little use.
|
| Now, obviously the error isn't totally useless as an error can be
| returned to indicate, say, the connection to the database was
| dropped. But even in that case, the definition of a transaction's
| validity/lifetime means that even if rollback fails, the
| transaction is in the same state as if rollback had succeeded.
| thriftwy wrote:
| Obviously, transaction may fail to be rolled back and leave
| dangling locks. Not sure about the specifics.
| marcosdumay wrote:
| That's a bug in your database, not something you specify on
| your API.
| thriftwy wrote:
| What if it's a connection problem? DBs are normally remote.
| It's also OK to specify potential bug surface on your API.
| thwarted wrote:
| The bug being referred to isn't the connection problem,
| the bug is that in the event of a loss of communication
| with the client, the transaction isn't fully cleaned up,
| including the release of held locks, when the transaction
| enters an abortive state.
| thriftwy wrote:
| It often takes minutes to hours for a connection to be
| reset when one of its sides went away. So no, it's quite
| often that one side will get these exceptions while the
| other one is locked up for prolonged period of time.
| thwarted wrote:
| I don't think that "leave dangling locks" is obviously a
| possibility from rollback failing. What's the method to clean
| up those locks? Rollback harder? Commit? If a transaction is
| ever aborted and there's a chance that locks specific to the
| transaction (MVCC locks necessary for transactional
| semantics) are still held then it would be safest to always
| issue this mythical "clean up locks" statement after every
| rollback attempt.
|
| The default final state of a transaction that is not
| explicitly committed (and even autocommit is still explicit)
| is that it is aborted, purely because the _only_ way a
| transaction can be committed is by commiting it vs there are
| _an infinite number of ways and reasons_ for the transactions
| to abort. If the rollback is successful or not there is
| logically no way that the state of the transaction after
| rollback being invoked is that the transaction is still
| usable for something.
| pmarreck wrote:
| I unexpectedly shuddered at the term "dangling locks"
| marcosdumay wrote:
| Or the Java SQL connection interface, that can throw
| SQLException on close(). Yes, if your connection throws an
| error when closing, I guess it stops being usable.
|
| Has anybody ever did something useful with that exception?
| hyperman1 wrote:
| I've seen this happen in Oracle using two phase commit, when
| the transaction coordinator drops dead before transmitting a
| commit or rollback decision. The transaction remained in doubt
| for months before someone noticed.
|
| You can ask around and manually coordinate a decision, and tell
| the databasecwhat you decided.
| thwarted wrote:
| Oh that's interesting, and probably manifests a bunch of
| issues related to storage and rollback segments being
| consumed with the transaction staying open for months.
|
| But that's not the same thing as rollback failing (although
| it is the _invocation of rollback_ failing) as neither
| rollback nor commit was fully issued and received, so it
| makes sense that the transaction would stay open (given that
| the database doesn 't tie transactions to the a connection or
| a session, and for a two phase commit scenario I'd expect the
| transaction coordinator to "own" the transaction so it's
| lifetime isn't necessary tied to a session).
| hyperman1 wrote:
| Yeah, the story is a bit incomplete. The full chain was
| application->transaction master -> 20 or so slave
| databases. It was a weekly batch dispatching data to the 20
| slaves, starting with a full delete of each slave.
|
| Someone decided to literally pull the plug and replace the
| master database server node from the rack, while the batch
| was still running. He assumed the other server nodes would
| pick up where this one left off. So the batch log of the
| application first complained about the master disappearing,
| then about the rollback failing on another master node
| because it wasn't the coordinator and had no idea of this
| transaction.
|
| It also means the decision about the commit/rollback was
| irrelevant, as next week's batch run had deleted the
| records in question. Presumably, some ephemeral records
| were hanging around, deciding if they were deleted either
| in week X or week X+1.
| 4RealFreedom wrote:
| Not exactly the same but an engineer I was working with wasn't
| handling a failure case properly and leaving transactions open.
| It was reported that the DB would stop working after a certain
| amount of time. I knew transactions were hanging but I didn't
| understand why. I sat down with the engineer and QA trying to
| figure out the problem for well over a day. QA was running
| their test suite over and over. We started removing pieces one
| at a time until we found the problem.
| shpx wrote:
| Pending and rolled back are different transaction states. The
| former uses resources and locks and can prevent other
| transactions from happening.
|
| Rolling back a transaction twice probably indicates an error in
| your program, which Go's API is giving you a chance to report
| to yourself.
|
| Ultimately every network request can fail because of the Two
| Generals' Problem. Actually, every single operation on a
| computer can fail (as in, do something other than what you were
| promised or promised yourself it would do). Nothing in life is
| guaranteed, the environment is adversarial. The fact that we
| create machines that can be predicted with 0.00000000001%
| certainty and carve out a safe environment for them and feed
| them energy is not common and unnatural and all computers will
| also eventually succumb to entropy. The network is just where
| that is common enough that considering that another computer
| can die in our programs can be more useful than completely
| ignoring the possibility. This possibility is represented as a
| non-zero number called "error" in the Go API you've posted, so
| that you have the option of branching your program to a
| different execution path if the database you're communicating
| with stops existing or at least stops being reachable.
| haiku2077 wrote:
| Falsehoods programmers believe:
|
| - Sleep(1) sleeps for exactly 1 second.
|
| - Sleep(1) sleeps for approximately 1 second.
|
| - Sleep(1) sleeps for at least 1 second.
|
| - Sleep(1) sleeps for an unknown, but short amount of time.
| Certainly not weeks, months or years.
| teddyh wrote:
| More _Falsehoods programmers believe about time_ : <https:/
| /gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...>
| Dylan16807 wrote:
| "Approximately 1 second" is fine. You just have to keep in
| mind that other influences can block your program from
| running. Those other influences can trigger even if you
| don't sleep!
| a1369209993 wrote:
| > Sleep(1) sleeps for approximately 1 second.
|
| This is correct; the problem is you're confusing the 95%
| confidence interval (which might be as narrow as
| (999ms,1001ms) for some reasonable designs) with the
| absolute error bounds (which are (0ms,[?]ms], and yes, the
| infinity end _is_ inclusive).
| haiku2077 wrote:
| An example of how a rollback could fail is if the database is
| accessed over a network and the connection times out due to a
| networking problem.
| Groxx wrote:
| > _Does a failed rollback mean (logically) that the transaction
| is still open and uncommitted?_
|
| Yes, it means exactly that until something else manages to
| close the transaction.
|
| Generally that's done by noticing that the connection has
| failed, or a timeout has expired, assuming "roll back unless
| confirmed" is the default behavior (usually true, but not
| always).
|
| The reason you might want to _explicitly_ tell something to
| roll back is to shorten ^ that latency, or to wait for it to
| complete before doing something else that requires it to be
| gone.
| kazinator wrote:
| It's very easy.
|
| "This message does not exist" can be taken to be a false
| statement, without introducing any contradiction.
|
| It is not like "this message is false" (Liar's Paradox) or "this
| sentence has no proof" (Godel's sentence).
|
| Unfortunately, just because "this message does not exist" is a
| false statement, contradicted by existential evidence, doesn't
| mean that the remaining claims next to it can be dismissed as
| false.
| kelnos wrote:
| Perhaps not, but if one encounters a false statement, then it
| is reasonable to assume any following (and previous) statements
| are suspect as well.
|
| Also I think you are missing the point. This is clearly written
| tongue-in-cheek. The author is being entirely rhetorical;
| they're not asking you to solve the apparent inconsistency.
| They just thought the error message was silly, and that working
| through it logically (as if each statement in the error message
| is true and correct) is a funny exercise.
| pieresqi wrote:
| I find the message self explanatory.
|
| Outlook is server authoritative. Message does not exist on server
| and thus it can't be saved.
|
| But it is available on that client - client was able to load it
| before it was removed from server - and such it can be copied out
| or discarded from client.
| rzzzt wrote:
| > A returned value of 1 seems to say, "I'm here, but you can't
| use me." > Strange as it may seem, that's exactly what is
| going on. A return code of 1 > means we're not allowed to
| install the print spooler because interrupt 47 > is being
| used for some other purpose by some other interrupt handler. This
| > is a fascinating bit of business to contemplate.
|
| https://archive.org/details/The_Peter_Norton_Programmers_Gui...
|
| To me it sounds like that the service hogging interrupt 47 is
| saying that it can't be used for print spooling purposes.
| Waterluvian wrote:
| Any semantic pedantics that involve discussing ontology is always
| a fun time. This was a fun read.
| rufus_foreman wrote:
| Nor will it ever exist.
| kreeben wrote:
| Me:
|
| Browser:
|
| Server: WTAF are you trying to do, here, man?
|
| Message: Hi everybody!
| mrmanner wrote:
| It has ceased to be
| berryg wrote:
| :-) The Dead Parrot Sketch,
| https://en.wikipedia.org/wiki/Dead_Parrot_sketch
| projektfu wrote:
| ... As always, should you or any member of your IM Force be
| caught or killed, the Secretary will disavow all knowledge of
| your actions.
| joezydeco wrote:
| Currently working in a Microsoft-enabled corp with a very
| aggressive document retention (i.e. _deletion_ ) policy. This
| message doesn't surprise me at all. Stuff just...disappears. All
| the time.
| cortesoft wrote:
| Oh, finally a chance to put my Philosophy degree to use!
|
| The error says the "message" does not exist, but the message is
| not the same as the text. The message is an object that can be
| saved or discarded, and it contains text.
|
| The text still exists and can be copied, but the message is gone
| and can't be saved anymore.
| Rastonbury wrote:
| "the message does not exist in our system, only in your browser
| as text, copy and save it if you want to keep it, if you
| refresh this page the text will disappear"
| tikhonj wrote:
| It's still funny that the text of a message can exist without
| being a message itself. That must make sense in the specific
| context of Outlook, but it shows that the conceptual design of
| the software does not match how we want to think about the
| domain abstractly.
| sherburt3 wrote:
| I don't think the model is that far off. In real life I can
| read a letter and retain the contents in my mind, then burn
| the letter.
| m463 wrote:
| if the message never achieved a physical form such as printing,
| does the message exist?
|
| if the message stopped existing, but nobody was there, did it
| make the trash-can sound?
| mananaysiempre wrote:
| Ceci n'est pas un message?
| 31337Logic wrote:
| Excuse me but Kant would like a word with this dev.
| ttfkam wrote:
| Ceci n'est pas un message.
| chuckadams wrote:
| Reminds me a lot of "The operation failed with an error: success"
| layer8 wrote:
| This message means something analogous to: "You loaded a file,
| but now the file doesn't exist anymore (on disk), so I can't
| update it with your changes. You can discard the loaded copy, but
| consider copying its contents first and create a new file from
| it, because for some technical reason I can't do this myself."
| ggarnhart wrote:
| This reminds of a choice I once saw between the following: "Save
| this Credit Card" Or "Never save this Credit Card"
|
| With hashing and things, the latter is certainly possible, but I
| got a good chuckle out of it.
| kstrauser wrote:
| Along those lines, "Don't use cookies on this site".
| MikePlacid wrote:
| I do not think you need a philosophical degree to handle this. A
| law degree is enough. Just add "legally" before "exist" and
| everything makes its perfect legal sense again.
|
| Indeed, since this person... I mean message - is not in the list
| of ones legally allowed to exist, you can't hire it, can't fire
| it, the only thing you can do with it legally - is to kill it.
| But that does not prevent you from searching its pockets first
| and making use of its valuables.
|
| (Sorry for the gallows humor).
| routerl wrote:
| Isn't all of this just equivalent to a pointer? "This variable
| doesn't exist" is a reasonable error message when you're, for
| example, dereferencing a pointer with a wrong data type: it could
| be the equivalent of "there's no integer at this address" or
| "this integer doesn't exist".
|
| The problematic "this" is just an indexical in that case, and it
| works fine in terms of ontology, just like we might say "this
| house doesn't exist", while pointing at a burned up lot. Any
| fluent speaker of English will understand that, just like how
| they'd understand a description of the Parthenon as "this is a
| great temple", while looking at a ruin.
|
| "This email doesn't exist" is not really problematic; the
| metadata persists but the body and subject have been deleted,
| plus whatever else constitutes "a message" in this schema. We can
| refer to it, because the pointers still exist, but the value at
| the address is gone.
|
| The house might not exist anymore, but the address still does.
| Dylan16807 wrote:
| Your pointer scenario could have the same warning, but it does
| not match the scenario in the post. In the post, we have """the
| message""" displayed on screen. It's not a simple dangling
| pointer, the contents are right there.
|
| We're standing inside the living room while saying the house
| doesn't exist. And as soon as we walk out the living room will
| disappear.
| routerl wrote:
| I'm sorry, I miss things nowadays, but I don't see where the
| post states that the message is still available.
|
| If it is, that's probably a desync issue, like others have
| said. Still not particularly mysterious or ontologically
| interesting. So much of parallel and distributed programming
| is about solving desync problems.
| Dylan16807 wrote:
| > I'm sorry, I miss things nowadays, but I don't see where
| the post states that the message is still available.
|
| I put it in super scare quotes for a reason, because it
| depends on what you mean by "message".
|
| But the _text_ is still on the screen. That 's why you can
| copy it.
|
| > If it is, that's probably a desync issue, like others
| have said. Still not particularly mysterious or
| ontologically interesting. So much of parallel and
| distributed programming is about solving desync problems.
|
| If it's just a desync, then it could resync things if it
| wanted to. Instead it gives a confusing and contradictory
| warning.
|
| The way the warning contradicts itself is pretty
| interesting, and I and the author think it's fun to delve
| into how the word "message" is supposed to be defined here,
| and how it's causing problems.
|
| But it's not simply a reference to a thing that's gone.
| It's not actually gone yet. It's a ghost.
| mFixman wrote:
| If it were a pointer, Microsoft's advice of copying the message
| would cause a segmentation fault.
|
| Maybe a better comparison would be a weak reference to an
| object that's in line to being garbage collected.
| routerl wrote:
| Yeah, I said "the equivalent of a pointer" because it was an
| analogy. I then spent the rest of the post trying to cash-in
| that analogy. Sorry I wasn't clear enough.
| NayamAmarshe wrote:
| The message is the glue that binds reality and unreality. It
| exists, existed, never existed, all at the same time.
|
| It is the paradox of creation, of existence, of dissolution and
| of consciousness.
| satisfice wrote:
| My favorite Windows error message:
|
| "Unknown device (not found)"
| jacobsenscott wrote:
| I suspect it means the message only exists client side, and they
| are able to detect that somehow. So if you browse away, or
| refresh, or whatever, it is gone.
| sva_ wrote:
| The koan of the message that never existed.
| astrea wrote:
| Wait until the author learns about pointers.
| redbell wrote:
| We used to hear that LLMs _hallucinate_ but, apparently, we are
| witnessing the hallucination of apps now!
|
| This reminds me of another _quiet funny_ error message, again,
| from Microsoft about a Windows Phone error message telling users
| to "insert CD and _Restart Your Computer_ " (
| https://thenextweb.com/news/this-is-the-funniest-windows-err...)
___________________________________________________________________
(page generated 2024-06-01 23:00 UTC)