axiomhq/next-axiom

Sending front end logs with "fields" attribute results in a 400 (on Vercel)

stefl opened this issue · 5 comments

stefl commented

I am seeing repeated 400 errors with axiom logs for front-end logs in production.

For instance, this call (where connectors is an empty array):

log.debug("getConnectors", { connectors });

Generates a request with this body

'[{"level":"debug","message":"getConnectors","_time":"2023-05-24T10:02:53.039Z","fields":{"connectors":[]},"vercel":{"environment":"production","source":"frontend"}}]'

This throws a 400 and returns {}.

If I manually trigger this same request using curl using this body:

'[{"level":"debug","message":"getConnectors","_time":"2023-05-24T10:02:53.039Z","vercel":{"environment":"production","source":"frontend"}}]'

I get a 200 back.

If I send a message that generates this body, everything is also fine:

[{"level":"debug","message":"Page loaded /my/path","_time":"2023-05-24T10:02:46.300Z","fields":{},"vercel":{"environment":"preview","source":"frontend"}}]

Is it not possible to log a Javascript object/array to Axiom or is this a bug?

hmmm, that should be fine, the payload looks correct to me. can you provide more info on

  • which next and next-axiom versions are you using?
  • and is this on vercel platform with axiom integration enabled?
  • does the 400 error has a description saying why it fails?
  • have you tried other log lines, are they are responding with 400?
stefl commented

@schehata Thanks for taking a look.

In our Package.json:

"next": "^13.2.4",
"next-axiom": "^0.14.0"

And in PNPM lock:

  • next-axiom 0.14.0(next@13.2.4)
  • next 13.2.4(@babel/core@7.21.0)(react-dom@18.2.0)(react@18.2.0)

This is using the Vercel Axiom integration. We created the integration a few months ago, so perhaps I need to do it again?

The 400 does not give a description of the error, just an empty {} in the body.

Other log lines are working, so the credentials supplied by the Axiom integration appear to be correct. Anything that does not contain this second argument seems to be accepted fine:

@Stef screenshotted this on 2023-05-25 at 11 23 39@2x @Stef screenshotted this on 2023-05-25 at 11 24 09@2x

I thought this could potentially be Cloudflare blocking the /_axiom route because we have Cloudflare in front of the web app. But I've also tested on a Vercel preview and have the same issue.

Sometimes the logs send multiple log lines as an array. If any of those lines has a value for the "fields" key then the entire request will fail.

stefl commented

Hi folks, we are still experiencing this and are unable to rely on Axiom for logs. Can anyone help here? I'm happy to give you access to an account on our web app to see what's going on.

hi @stefl , I am sorry that you are facing such problems that is affecting your experience using Axiom. I have been trying to reproduce this but I couldn't. I have tried just now to send some logs with the second argument and it worked fine.

Screenshot 2023-06-21 at 11 14 09 AM

I took this back to the team, and I will hopefully get back with answers. The only guess I have at the moment is the number of columns you are sending, there is a limit of number of columns that could be saved, but otherwise the json you showed looks fine to me.

@stefl hey, does this problem persist? can you check the response of /_axiom/logs? it should print an error now.