I am filing this as a bug report but I am not sure if the "bug" is on the SEDE side or the chat side (or if this should be a chat feature request).

Issue: SEDE links to answers (or anything that isn't a question for that matter) in the [Post Link] column are not compatible with chat one-boxing.

Reason: SEDE always uses http://site/questions/id, no matter what the PostTypeId is (i.e. instead of http://site/a/id for answers).

SE's web servers seem to handle this properly and forward to the correct URL, but chat does not, and copying a generated answer link from SEDE into chat does not create a onebox as I would expect.

This is one way to frame the reason. It could also be said that chat does not handle 301's properly. Like I said, not sure where to consider the issue to be.

Also, rene's comment below leads me to point another finger at chat: It turns out chat does properly one-box links to answers in the form /q/id, it just doesn't handle /questions/id.


  1. In an SEDE query with a [Post Link] column linking to an answer, copy the link and paste it in chat.

Expected: One-box. Actual: No one-box (a ... zero-box?)

Possible Solutions:

  • Make SEDE generate [Post Link] URLs based on PostTypeId, or
  • Make chat be able to one-box /questions links to answers, or
  • Make chat follow the 301 status replies the server sends back before one-boxing, or
  • Make SEDE generate links of the form /q/id instead of /questions/id.

The first solution probably comes at too high a cost: While the links are formatted client-side, the query needs to return the title column in the response when the magic column is present. Letting it be based on PostTypeId means adding extra overhead to the response when the magic column is used.

I believe that the third solution (follow 301 replies) is philosophically the best except that in practice it isn't really necessary since chat doesn't seem to one-box wiki or moderator nomination posts anyways (PostTypeId 3 thru 8), so unless support for those were added in general it wouldn't change anything vs. the other two options.

The fourth solution is from rene's observation in the comment below. This might be the quickest fix, since it doesn't really require changes to anything other than SEDE's client-side link formatting code.

Also I'm not entirely sure about my claim that the web servers handle /questions properly for all post types, I'd need to do some more thorough testing, and I don't want to stray too far from the topic here (answer links). I can only say for certain that it works for questions and answers.



SELECT TOP 2 Id [Post Link], Id, PostTypeId
  FROM Posts 
  WHERE PostTypeId = 1 AND DeletionDate IS NULL 
UNION SELECT TOP 2 Id [Post Link], Id, PostTypeId
  FROM Posts 
  WHERE PostTypeId = 2 AND DeletionDate IS NULL 

Chat results:

  • IIRC Post Link is expanded client-side. You don't have the PostTypeId anymore so you can't decide there if it needs to be a q or on a. A quick experiment reveals that using http:\\site\q\{id} does one-box correctly. So that might be the fix
    – rene
    Mar 30, 2017 at 8:04
  • @rene I was thinking along those lines too, but what I found was this: The link is formatted client side but if you look at the server response to, say, select id as [Post Link] from posts, it's the server that adds the extra needed info to the response: The response to that query includes the title column queried from the db. So it wouldn't be unreasonable to have it add posttypeid as well, the server is already querying for the extra info needed for the client to build the link. Good catch with \q\. I'm leaning even more towards calling this a chat issue now.
    – Jason C
    Mar 30, 2017 at 10:59
  • 1
    let me link to my answer about site:// expansion here and here. The /q/ fix might be preferable as I can prep that PR today and then submit for a pull by Nick in 6 to 8 weeks. Not sure if the chat onebox regex is going to be touched in that same timeframe.
    – rene
    Mar 30, 2017 at 11:06
  • @rene Agreed about /q/: It's the quickest, simplest fix, by far.
    – Jason C
    Mar 30, 2017 at 11:07
  • 1
    I have prepared the commit here but haven't created the pull request yet. This first needs feedback from Tim or Nick in case they rather fix the chat logic.
    – rene
    Mar 30, 2017 at 21:13
  • Should that be SELECT TOP 2 Id **AS** [Post Link]?
    – tripleee
    Apr 23, 2017 at 19:24
  • @tripleee AS is optional. Same effect. Full syntax at docs.microsoft.com/en-us/sql/t-sql/queries/…
    – Jason C
    Apr 23, 2017 at 19:30
  • @rene Maybe you should just make a pull request and see what happens.
    – Jason C
    May 31, 2017 at 17:35
  • 1
    @JasonC done here
    – rene
    May 31, 2017 at 18:29

1 Answer 1


The magic column Post Link is expanded client-side. The PostTypeId isn't send in the payload to the client so you can't decide there if it needs to be a /q/ or on /a/. A quick experiment in chat reveals that using https:\\site\q\{id} does one-box correctly for both answers and questions.

So for now that will be the fix as that can be prepared by a simple Pull Request on the SEDE repository.

The change is on these lines in query.resultset.js:

case 'post':
     return linkFormatter('/questions/', siteColumnName);

will become:

case 'post':
     return linkFormatter('/q/', siteColumnName);

I have tested this locally and renders the correct result. I have gone ahead and submitted this Pull Request that only needs to be merged on the main branch by Nick in 6 to 8 weeks. The PR already received a thumbs up from Tim Stone so we're good to go.

You must log in to answer this question.

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