I came across this question that practices the behavior: The accepted answer isn't submitted by the question asker, but it's not pinned on top. Why?


Note: For the sake of explanation, I removed post content and comment area via web front-end manipulation, otherwise my screen won't be tall enough to take the above screenshot.

  • 1
    The timeline shows it was deleted and undeleted; maybe that has to do something with it?
    – Glorfindel Mod
    Commented Nov 18, 2019 at 10:48
  • 2
    @Glorfindel Related: Deleted accepted answer pinned as top answer Commented Nov 18, 2019 at 10:49
  • 3
    Um... isn't there a rule that freehand circles should be red? However, one could imagine sequences of actions that might lead to this effect. E.g. that the poster was dissociated from the Q and the A separately. Someone who can provide the timelines of the posts could shed some light on this. Right now, one can only guess.
    – Marco13
    Commented Nov 18, 2019 at 11:41
  • 2
    Is it possible that the answerer-account was merged with the asker-account? It would then be a self-answer, but then I wonder why the answer still caries the "old" user id. One currious thing is that the answer was accepted by Community: physics.stackexchange.com/posts/514020/timeline .. when does that happen?
    – Tom
    Commented Nov 18, 2019 at 11:42
  • 4
    @Tom the original accepting user got deleted, so acceptance is moved to Community. Same happens with bounties if the user that posts the bounty is deleted.
    – yivi
    Commented Nov 18, 2019 at 11:50
  • @Rubiksmoose Reproducible even with TamperMonkey disabled. Commented Nov 18, 2019 at 14:00
  • @iBugsaysReinstateMonica I realised I could test that myself lol. Oops! Looks the same to me. Interesting. Commented Nov 18, 2019 at 14:00
  • Counterexample: Old Q&A, migrated, user whom wrote accepted answer no longer active, yet their accepted answer rises to the top. --- This bug was suggested but not implemented here.
    – Rob
    Commented Nov 18, 2019 at 14:25
  • @Rob Not a good example I would say. The top answer, in addition to being accepted, is also the top-scored one. You might want to bring another example where the accepted answer isn't the top-scored. Commented Nov 18, 2019 at 14:34
  • Read the first word again.
    – Rob
    Commented Nov 18, 2019 at 14:35
  • @Rob Sorry, but I still don't understand why it's a bug - top-scored and accepted answer pinned at top sounds perfectly OK. Commented Nov 18, 2019 at 15:00
  • 2
    @iBugsaysReinstateMonica If it would had the same bug, then the answer wouldn't be the top when sorting the answers by "active" or "oldest" (there are more recent answers and it isn't the oldest). Since it stays pinned the "accepted" vote really counts there. I guess that is why Rob wrote "counterexample".
    – Tom
    Commented Nov 18, 2019 at 15:09
  • 1
    @Tom Got your (and Rob's) point. Thanks Commented Nov 18, 2019 at 15:37
  • This may not be meme-compliant. Commented Nov 18, 2019 at 22:40
  • Just ran into another example of this.
    – Em C
    Commented Dec 17, 2019 at 14:34

1 Answer 1


Funny story...

That answer and its question were posted by the same person, using two different accounts. When this was discovered, moderators deleted the sockpuppet account and the owner of the other account requested that one be deleted as well.

So in a sense, the system was doing the right thing here - not pinning a self-accepted answer - but, it was doing so for the wrong reason: with both authors gone, the relevant comparison boiled down to, if ( null == null )!

Naturally, there are thousands of other cases where both authors are gone but without sockpuppets being involved. In those cases, it's clearly undesired behavior to unpin... So starting today, those will behave normally unless the system knows the authors were the same.

  • 1
    Out of curiosity, what variable is resolving to null here? Presumably there's still some latent account information, or we wouldn't be seeing the distinct, "defaulted" usernames? Commented Jan 11, 2020 at 15:38
  • There's a string on the post record itself - OwnerDisplayName - that is set to "userNNNN" or whatever on user deletion; that's the fallback here. IIRC, that info is in the public data dumps too - you'll find similar logic in many queries that deal with post ownership.
    – Shog9
    Commented Jan 11, 2020 at 17:12
  • I see! Interesting. (I haven't ever really played with the dumps.) Commented Jan 11, 2020 at 18:55
  • "denormalized" is probably more accurate though still wrong as in this scenario there is no longer a normal form - the field becomes the source of truth upon user deletion (slightly more complicated in Teams but still true for most practical purposes). The system was originally designed to work just fine without the concept of a User Account at all, and still retains some support for this in key places.
    – Shog9
    Commented Jan 11, 2020 at 19:01
  • Sounds sensible. My initial instinct was that this was maybe not the best approach, that you'd be better off keeping the account links but just nuking all the personal info on the account and anonymising the display name. But then I realised that the denormalisation is probably part of the point: the links between different posts could be considered identifying information (especially when considering pings in any lingering comment threads under said posts) Commented Jan 11, 2020 at 19:04
  • It could be made to work either way; this was an early design decision that, initially, had as many privacy issues as a "deactivated" account system would have... We've just had a decade+ to patch them up at this point. Regardless of approach, privacy has to be an intentional goal or... It becomes an accident waiting to happen.
    – Shog9
    Commented Jan 11, 2020 at 19:29
  • Yep, definitely. Glad it's taken into account. Commented Jan 11, 2020 at 20:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .