500 error at old URL for numeric tag (Google crawl fail)

Contribute UX
1

My forum has a tag which happens to be a 4 digit number, 6309. It’s been around for a while. It displays OK on posts, and the URL in that case is /tag/210-tag/210

But rather than a pretty 404 page, a url like /tag/6309 is returning a server error:

Oops

The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience.

I’m guessing that some time previously that was a valid way to refer to the tag. Because it’s a server error, google’s crawler is complaining to me about it.

Tag page looks like this:

image
image902×616 110 KB

I think 404 would be correct.

2 Likes
2

Yeah, that’s not pretty:

image
image1660×275 33.5 KB

ActionView::Template::Error (No route matches {action: "tag_feed", controller: "tags", tag_id: "9999"})
  app/views/list/list.erb:136
  app/views/list/list.erb:134
  lib/topic_list_responder.rb:16:in 'block (2 levels) in TopicListResponder#respond_with_list'
  lib/topic_list_responder.rb:7:in 'TopicListResponder#respond_with_list'
  app/controllers/tags_controller.rb:223:in 'block (2 levels) in <class:TagsController>'
  app/controllers/tags_controller.rb:229:in 'TagsController#show'
  app/controllers/application_controller.rb:447:in 'block in ApplicationController#with_resolved_locale'
  app/controllers/application_controller.rb:447:in 'ApplicationController#with_resolved_locale'
  app/controllers/application_controller.rb:1098:in 'ApplicationController#ensure_dont_cache_page'
  lib/middleware/omniauth_bypass_middleware.rb:35:in 'Middleware::OmniauthBypassMiddleware#call'
  …

We should fix that error; we also might be able to fallback to looking for an all-numeric tag name if the tag id isn’t found.

Wayback first noticed that tag appearing on 2025-05-13 and its url was https://retrocomputingforum.com/tag/6309 which worked at the time and up until 2025-12-16.

image
image1287×775 105 KB

1 Like
6

Ah, well-spotted. Perhaps some sort of 3xx redirection response would be right, even better than 404, in case the tag is valid?

10

(I’m not sure if this should be in the UX or Bug category.)

2 Likes
11

All good. We have eyes on this issue and will be issuing a fix.

Tag name resolution at /tag/name should and must remain compatible, this is an explicit choice and decision we’ve made. But I think in this case it’s a number so perhaps the name resolution must have gone wrong at the backend.

4 Likes