More microsoft would be a 5 minute message on screen promising that they have never and will never misplace any of your messages, right before this monstrosity appears
The developer doesn’t know what went wrong and things definitely don’t go wrong all the time at Microsoft! This is as surprising to the developer as it is to you!
It’s also pleasantly humane, not like “ERROR:”, meaning it’s more of a silly and fun oopsie doopsie than a systems engineering failure.
Don’t you just feel better as the user seeing that? It’s not the systems engineer’s fault and neither is it yours. It just kind of happened. What even is “it”? No one knows! Computers are weird — eh? Nothing like a whimsical hiccup in your computing to brighten the day.
Whatever you were doing, whether it’s saving work, buying something, or completing critical forms, some of that was probably done, or maybe not, but who really knows? Hehe, not us — we are just as surprised!
Oh, and don’t call support with this stuff. There’s not enough to go on even if you reported it for us to investigate. It’s just one of these things, you know?
Forget about it and move on buddy! You’ve got an essay to rewrite/a purchase to figure out/a critical form to complete again, and who knows what will happen then! Will it go through? Maybe, maybe not. It will be surprising if it doesn’t! Isn’t it just so exciting?
Damn straight. This came up in an earlier discussion about languages that rely heavily on exceptions - they sensibly don't want to expose backtraces so you get this `try: response_handler() except: print("oops!")` nonsense because the programmer literally doesn't know what went wrong and they're sure as hell not going to give you the details.
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.
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.
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.
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.
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?
Depending on the durability guarantees of the database/connection in question and whether it uses request pipelining, I could imagine it indicating something like "non-clean connection shutdown; your last few commands might not have been processed"?
There's a similar situation in raw socket programming in some OSes: You might be done writing all your outbound data into the socket (i.e. your last write() call returned indicating success), but the receiving application might crash before being able to read all of your data.
By implementing an application-level shutdown command that the other side acknowledges, that can be avoided; maybe some SQL protocol implementations do that, and that exception is thrown if the shutdown request is never acknowledged.
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.
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).
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.
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.
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.
"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!
This is correct - Sleep(1) does sleep for approximately 1 second; 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).
If your software is running on a VM, and that VM is suspended (e.g. for migration), the end of sleep could be minutes or months in future.
This is surprisingly common when running on certain VM instance types on public cloud! Common enough that I've had to account for it in production code.
The confidence interval comment still applies for any production or client environment I've ever deployed code to.
Unless you actually expect your environment to spend more than 5% of its time on average getting suspended and resumed. Maybe you work on some tooling that is scheduled to run right around migration time (for servers) or sleep/resume time (for clients).
>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.
Remands me of "Operation failed successfully" errors. It was a meme, but in some cases I had to implement failing an operation in a test service fake and log something like that.
"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" (Gödel'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.
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.
The statement has a true interpretation. "This message" can be interpreted as referring to some object in a back-end database represented by text you see in the UI. The thing you see on the screen corresponds to no persistent representation in the system.
"This person does not exist" under an AI-generated image similarly tells the truth; the image is not the person.
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.
> 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.
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.
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.
"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"
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.
This letter cannot be read because it has been burnt to ash. You can only throw away the ashes. Make sure you read the letter and retain the contents in your mind, before you throw away the ashes, if you want to use them later.
I would assume Outlook means that its locally-cached copy of the message exists, but the original server-side (probably IMAP) message no longer exists. And that without that message, there's no server-side resource to update — just a resource representation of a snapshot of that server-side resource, still temporarily persisted in a client-side read-through cache.
> the original server-side (probably IMAP) message no longer exists.
Doesn't Outlook rely on the Exchange mailstore?
It's a long time since I was near to Outlook and Exchange, but I thought the Exchange mailstore was some kind of X400 abomination, and that the IMAP capability was a bolt-on.
What substantial difference is there between a message being manifested physically via printing as opposed to having it be a collection of bits in specific states on your hard drive (or memory, for that matter)?
In what way are magnetic patterns unsubstantial? You can read information from them, which is really what we’re trying to do here, isn’t it?
Is the goal to have it be readable to the naked, nominally working human eye? If so then I’d wager you could use magnetic paper as storage if you were a particularly persistent driver developer.
>if the message stopped existing, but nobody was there, did it make the trash-can sound?
I know the answer for the case where this question refers to something on my pc. I have disabled audio warnings, alerts, etc so if the message stopped existing and I wasn't around to notice then it clearly does not make a trash-can sound.
> if the message never achieved a physical form such as printing, does the message exist?
The physical bits do exist, though, on the storage medium. Now, of course this does not match our usual image of existing, since the bytes were technically always there, but it still exists in the physical world.
You can actually make the same argument with a letter: The paper and ink were there before, the pattern ist what brought it to existence.
The author addresses this though. He calls it the contents instead of the text but it's the same thing.
> We learn a final affordance, which complicates the story. An inexistent message has contents, which may be copied – but only if the message has not yet been discarded.
The message is gone and can't be saved anymore, but it can still be discarded (or presumably not discarded).
The message object used to contain those contents, but then the message object was deleted, although the contents value was still available in a UI in temporary memory.
The sane will tell you that Necronomicon doesn't exist in our world, yet we have a vague idea of what it contains and we're sure that it contains only the most repulsive of things.
Example: You are editing a table row with some application, but when you try to save the changes, the system discovered that the row has been deleted from the table. The business logic does not permit you to create rows arbitrarily, so a new row cannot be inserted instead of updating existing one.
The behavior admittedly does not make sense for files (although I suppose you could rename or delete the directory that contains it), but it's sort of unavoidable if you don't want to take locks while some client application you don't control may or may not make changes.
Like people who’s bodies are gone but who’s souls are still here? I see dead messages… :P
That distinction might be worthwhile, and it’s certainly true from a technical standpoint. But the real problem here is the message is not the same as the message. If that was referring to a single message it’d make a great philosophical problem. Unfortunately we’re just talking about a more boring problem of two different messages with two different texts where the text of one of them accidentally referred to the other one as ‘this’.
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.”
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.
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.
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.
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.
> 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.
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.
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.
277 comments
[ 2.4 ms ] story [ 274 ms ] threadI 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.
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".
I've seen teams messages on firefox and safari about features not existing "download the teams native app!"
The developer doesn’t know what went wrong and things definitely don’t go wrong all the time at Microsoft! This is as surprising to the developer as it is to you!
It’s also pleasantly humane, not like “ERROR:”, meaning it’s more of a silly and fun oopsie doopsie than a systems engineering failure.
Don’t you just feel better as the user seeing that? It’s not the systems engineer’s fault and neither is it yours. It just kind of happened. What even is “it”? No one knows! Computers are weird — eh? Nothing like a whimsical hiccup in your computing to brighten the day.
Whatever you were doing, whether it’s saving work, buying something, or completing critical forms, some of that was probably done, or maybe not, but who really knows? Hehe, not us — we are just as surprised!
Oh, and don’t call support with this stuff. There’s not enough to go on even if you reported it for us to investigate. It’s just one of these things, you know?
Forget about it and move on buddy! You’ve got an essay to rewrite/a purchase to figure out/a critical form to complete again, and who knows what will happen then! Will it go through? Maybe, maybe not. It will be surprising if it doesn’t! Isn’t it just so exciting?
I find it as infuriating as you.
The answer to "how can I find all SharePoint Sites where I am a member?" is:
> Search SharePoint for contentclass:STS_Site
How is this, and op, cluster f possible? How do these decisions get into prod?
Consider this definition from go's database/sql package.
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.
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.
Has anybody ever did something useful with that exception?
There's a similar situation in raw socket programming in some OSes: You might be done writing all your outbound data into the socket (i.e. your last write() call returned indicating success), but the receiving application might crash before being able to read all of your data.
By implementing an application-level shutdown command that the other side acknowledges, that can be avoided; maybe some SQL protocol implementations do that, and that exception is thrown if the shutdown request is never acknowledged.
You can ask around and manually coordinate a decision, and tell the databasecwhat you decided.
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).
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.
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.
- 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.
This is correct - Sleep(1) does sleep for approximately 1 second; 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).
This is surprisingly common when running on certain VM instance types on public cloud! Common enough that I've had to account for it in production code.
Unless you actually expect your environment to spend more than 5% of its time on average getting suspended and resumed. Maybe you work on some tooling that is scheduled to run right around migration time (for servers) or sleep/resume time (for clients).
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.
"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" (Gödel'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.
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.
"This person does not exist" under an AI-generated image similarly tells the truth; the image is not the person.
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.
To me it sounds like that the service hogging interrupt 47 is saying that it can't be used for print spooling purposes.
Browser:
Server: WTAF are you trying to do, here, man?
Message: Hi everybody!
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.
If it can show you the content, the container must exist!
Doesn't Outlook rely on the Exchange mailstore?
It's a long time since I was near to Outlook and Exchange, but I thought the Exchange mailstore was some kind of X400 abomination, and that the IMAP capability was a bolt-on.
if the message stopped existing, but nobody was there, did it make the trash-can sound?
Is the goal to have it be readable to the naked, nominally working human eye? If so then I’d wager you could use magnetic paper as storage if you were a particularly persistent driver developer.
I know the answer for the case where this question refers to something on my pc. I have disabled audio warnings, alerts, etc so if the message stopped existing and I wasn't around to notice then it clearly does not make a trash-can sound.
The physical bits do exist, though, on the storage medium. Now, of course this does not match our usual image of existing, since the bytes were technically always there, but it still exists in the physical world.
You can actually make the same argument with a letter: The paper and ink were there before, the pattern ist what brought it to existence.
> We learn a final affordance, which complicates the story. An inexistent message has contents, which may be copied – but only if the message has not yet been discarded.
The message is gone and can't be saved anymore, but it can still be discarded (or presumably not discarded).
The behavior admittedly does not make sense for files (although I suppose you could rename or delete the directory that contains it), but it's sort of unavoidable if you don't want to take locks while some client application you don't control may or may not make changes.
Like people who’s bodies are gone but who’s souls are still here? I see dead messages… :P
That distinction might be worthwhile, and it’s certainly true from a technical standpoint. But the real problem here is the message is not the same as the message. If that was referring to a single message it’d make a great philosophical problem. Unfortunately we’re just talking about a more boring problem of two different messages with two different texts where the text of one of them accidentally referred to the other one as ‘this’.
With hashing and things, the latter is certainly possible, but I got a good chuckle out of it.
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).
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.
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.
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.
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.
Maybe a better comparison would be a weak reference to an object that's in line to being garbage collected.
It is the paradox of creation, of existence, of dissolution and of consciousness.
"Unknown device (not found)"