This PR addresses an issue where 404 (Not Found) logs were not being generated on the main gateway listening port when the control API was configured on a separate port. The root cause was that the NotFoundHandler, responsible for this logging, was only being assigned to the control API's router, leaving other listeners without it.

The fix centralizes the assignment of the NotFoundHandler into the proxyMux.setRouter method. This ensures that any router configured through this common function—whether for the main gateway listener or the control API—is consistently equipped with the 404 logging handler. To support this, the proxyMux struct is now explicitly initialized with the track404Logs configuration setting at startup.

Additionally, the 404 log entry has been enhanced to include the Host header from the request, providing better context for debugging. This new field is added conditionally, only when a non-legacy log formatter is in use, to ensure backward compatibility with existing log parsing setups. A new helper function, log.IsLegacyFormatter, has been introduced to detect the formatter type.

Files Changed Analysis

• gateway/api_loader.go: Removed the specific NotFoundHandler assignment for the control API router, as this is now handled centrally.
• gateway/proxy_muxer.go: The setRouter function now assigns the handle404 method to every router it configures. The handle404 logic was updated to use a new getLogEntryFor404 function, which conditionally includes the request's Host header based on the log formatter.
• gateway/server.go: The proxyMux struct is now initialized with the track404Logs configuration value in both NewGateway and startServer to ensure the setting is consistently applied.
• log/log.go: Added the IsLegacyFormatter helper function to check if the legacy text formatter is active.
• gateway/proxy_muxer_test.go & log/log_test.go: New tests were added to verify the conditional logging logic and the correctness of the IsLegacyFormatter function.

Architecture & Impact Assessment

• What this PR accomplishes: It ensures consistent 404 logging behavior across all gateway listeners, resolving a logging gap that occurred with specific port configurations.
• Key technical changes introduced: The responsibility for setting the 404 handler has been moved to the centralized proxyMux.setRouter function. The proxyMux struct now holds the track404Logs state, and 404 logging is enhanced with a conditional Host header to improve observability while maintaining backward compatibility.
• Affected system components: The changes affect the gateway's core HTTP server setup, request routing, and error handling logic, primarily within the gateway and log packages.

graph TD
    subgraph "Before"
        A["loadApps() for Control API"] --> B["Control API Router"];
        B -- sets handler --> C("router.NotFoundHandler = handle404");
        D["startServer() for Main Listener"] --> E["Main Listener Router"];
        E -- handler not set --> F((No 404 Logging));
    end

    subgraph "After"
        G["loadApps() for Control API"] --> H["Control API Router"];
        H --> I["proxyMux.setRouter()"];
        J["startServer() for Main Listener"] --> K["Main Listener Router"];
        K --> I;
        I -- sets handler on ALL routers --> L("router.NotFoundHandler = handle404");
    end

Scope Discovery & Context Expansion

The change is strategically placed in proxyMux.setRouter, a function that serves as a single point of configuration for all listeners managed by the gateway. This approach ensures that any listener will automatically inherit the correct 404 logging behavior. The introduction of IsLegacyFormatter to conditionally add the Host header is a key detail that prevents breaking changes for users with established log parsing pipelines. The impact is well-contained and effectively addresses the root cause of the bug.

References

• gateway/proxy_muxer.go: Centralizes the NotFoundHandler assignment and enhances the log message.
• gateway/api_loader.go: Removes the old, specific NotFoundHandler assignment.
• gateway/server.go: Updates proxyMux initialization to include the track404Logs configuration.
• log/log.go: Introduces IsLegacyFormatter to support conditional logging fields.

Powered by Visor from Probelabs

Last updated: 2026-05-15T06:37:50.824Z | Triggered by: pr_updated | Commit: 940b316

💡 TIP: You can chat with Visor using /visor ask <your question>

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Security Check Passed

No security issues found – changes LGTM.

Architecture Issues (2)

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (1)

Powered by Visor from Probelabs

Last updated: 2026-05-15T06:37:23.921Z | Triggered by: pr_updated | Commit: 940b316

💡 TIP: You can chat with Visor using /visor ask <your question>

API Changes

no api changes detected

Hi @MaciekMis can you please add tests?

Hey,
I did modify logging logic for 404 error due to comments in ticket. I have also included new test verifying that a proper log is logged.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
84.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

🎯 Recommended Merge Targets

Based on JIRA ticket TT-4023: Track 404 logs not showing in listening port when changing control api port

Fix Version: Tyk 5.8.15

Required:

• release-5.8 - Minor version branch for 5.8.x patches - required for creating Tyk 5.8.15
• master - Main development branch - ensures fix is in all future releases

Fix Version: Tyk 5.13.1

Required:

• release-5.13 - Minor version branch for 5.13.x patches - required for creating Tyk 5.13.1
• master - Main development branch - ensures fix is in all future releases

Fix Version: Tyk 5.14.0

⚠️ Warning: Expected release branches not found in repository

Required:

• master - No matching release branches found. Fix will be included in future releases.

📋 Workflow

1. Merge this PR to master first

2. Cherry-pick to release branches by commenting on the merged PR:

   • /release to release-5.8
   • /release to release-5.13

3. Automated backport - The bot will automatically create backport PRs to the specified release branches

🚨 Jira Linter Failed

Commit: 940b316
Failed at: 2026-05-15 06:36:33 UTC

The Jira linter failed to validate your PR. Please check the error details below:

failed to validate Jira issue: jira ticket TT-4023 has status 'In Test' but must be one of: Ready For Dev, Dod Check, In Dev, In Code Review

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

/release to release-5.8

/release to release-5.13

✅ Cherry-pick successful. A PR was created: #8225

✅ Cherry-pick successful. A PR was created: #8226