Incorrect error description for external endpoint failures

[paschun]

Describe the bug

The error description for external endpoint failures is often wrong. Often has the number 50 or 100 replacing the first few characters of the description. Other times it seems as if the string has been duplicated + shifted, replacing some characters in the string.

The message also changes upon refresh. Sometimes it is correct.

What do you see?

in the results[] from
/api/v1/endpoints/immich_home-to-tunnel-icmp/statuses?page=1&pageSize=50
If I expect ipv6-failed as the error message, it is instead:

    {
      "duration": 166000000,
      "errors": [
        "50v6-failed"
      ],
      "success": false,
      "timestamp": "2025-09-16T23:38:07.071688919Z"
    },

So it appears to be a backend/API issue.

What do you expect to see?

So if the message should be: error-message.
It will instead be 50ror-message, 100or-message, or something like essageor-message

List the steps that must be taken to reproduce this issue

1. Create an external endpoint in .yml

2. POST Data to the external endpoint like:POST /api/v1/endpoints/{key}/external?success={success}&error={error}

3. Open web interface

4. Hover over failure, or view it in the network requests

Version

Docker v5.23.2

Additional information

It doesn't appear to be related to duration. I tried including and not including the duration, the bug happens either way.

I'm using memory storage.

[TwiN]

Huh, that's weird.

I'll make a quick fix, and if you could test it to make sure it's no longer an issue, that'd be great

[TwiN]

@paschun when you have a minute, please give it a try

[paschun]

It's still happening with docker:latest

[TwiN]

@paschun Can you show me the exact command you're using to send a request? Because I can't replicate your issue.

FYI, I'm going to revert #1270 since I don't think it was related after all. Even before that change, I still can't replicate your issue using a curl command:

curl --request POST --url "http://localhost:8080/api/v1/endpoints/infrastructure_monitoring-agent/external?success=false&error=error%20message" --header "Authorization: Bearer secret-token-here"

[paschun]

I was using busybox wget. Here's a short script with GNU wget2 and curl.

#!/usr/bin/env bash
set -x
host="host"
key="key"
secret="secret"

success="false"
error="error-message-wget"
duration=""

wget2 -S -O - --header "Authorization: Bearer $secret" --post-data ''  "https://$host/api/v1/endpoints/$key/external?success=$success&error=$error&duration=$duration"

error="error-message-curl"
curl -v --header "Authorization: Bearer $secret" --request POST  "https://$host/api/v1/endpoints/$key/external?success=$success&error=$error&duration=$duration"

The requests are being forwarded through caddy, so I turned on caddy debugging, to view the requests server side. They look fine in the caddy logs.

caddy[5009]: {"level":"debug","logger":"http.handlers.reverse_proxy","method":"POST","uri":"/api/v1/endpoints/key/external?success=false&error=error-message-wget&duration=","headers":{"User-Agent":["Wget/2.2.0"],"Content-Type":["application/x-www-form-urlencoded"],"status":200}
gatus[4963]: 2025/09/17 22:15:31 [api.CreateExternalEndpointResult] Successfully inserted result for external endpoint with key=key and success=false

gatus[4963]: 2025/09/17 22:15:32 [api.CreateExternalEndpointResult] Successfully inserted result for external endpoint with key=key and success=false
caddy[5009]: {"level":"debug","ts":1758147332.1132944,"logger":"http.handlers.reverse_proxy", "method":"POST","uri":"/api/v1/endpoints/key/external?success=false&error=error-message-curl&duration=","headers":{"User-Agent":["curl/8.16.0"],"status":200}

Gatus is replying with 200 OK for both requests.
Oddly however, both error messages say 50ror-message-curl

[TwiN]

@paschun Thank you for your thoroughness. I was able to replicate it on my end. I'll look into it.

[TwiN]

So, I'm not sure why this is happening. There's clearly some data corruption shenanigans going on, and I dug quite a bit but wasn't able to find the root cause.

That being said, I was able to find a dirty, dirty hack, which I might end up using to "fix" it.

Right now, what I do know is that the number that shows up is the pageSize (50 is the default). If you change it to 9, for instance, it'll be 9rror-message-curl instead of 50ror-message-curl.

[TwiN]

I got it.

I'd like to pass the blame onto fiber, but the issue is mine entirely - I didn't read the documentation well enough.

This is from Fiber's library (note the last line in the comment)

// Query returns the query string parameter in the url.
// Defaults to empty string "" if the query doesn't exist.
// If a default value is given, it will return that value if the query doesn't exist.
// Returned value is only valid within the handler. Do not store any references.
// Make copies or use the Immutable setting to use the value outside the Handler.
func (c *Ctx) Query(key string, defaultValue ...string) string {
	return defaultString(c.app.getString(c.fasthttp.QueryArgs().Peek(key)), defaultValue)
}

This is from Gatus' code:

if !result.Success && c.Query("error") != "" {
	result.Errors = append(result.Errors, c.Query("error"))
}

Should be an easy fix.

[paschun]

I see, it was a string reference and not the string buffer value. Thanks!

https://docs.gofiber.io/#zero-allocation