Batch HTTP 400

[bddq]

Version

3.1.0

Steps to Reproduce

Trigger any event.
Wait for send to the /batch endpoint.

Expected Result

Expected HTTP 2xx code after send.
Expected to see some events in Activity feed.

Actual Result

No logs are shown in the Xcode console.
No events are shown in Activity feed on website.

Debug with breakpoint indicates a response status code is always 400 (PostHogApi.batch()) without any error.

SDK is initialised with:

let configuration = PostHogConfig(apiKey: postHogKey, host: "https://eu.posthog.com")

configuration.captureApplicationLifecycleEvents = false
configuration.captureScreenViews = false
configuration.debug = true

PostHogSDK.shared.setup(configuration)

[marandaneto]

@bddq I just checked it and it's working alright for me.
Usually, a wrong apiKey returns 401, but not 400.

What do you see in the logs if enabling configuration.debug = true?

[bddq]

@marandaneto As mentioned, logs are not displayed at all in Xcode console.
I'm using Xcode 14.2.

I checked the API key used. I use the right one.
I'm still having an HTTP 400 error.

I upgraded to 3.1.1, same issue.

[marandaneto]

@bddq we had some DNS issues yesterday, not sure if it's the same thing but I will double check.
https://status.posthog.com/incidents/qqslrk8p86hx

Would you mind trying it again? Can you test it using the US cloud (default host) for the sake of checking your connection/proxy/everything in the middle?

I will check why there are no logs as well.

[bddq]

@marandaneto I got same behaviour with default host.

BTW, I tested the same source code on another device and it works.
Device with PostHog working: iPhone 11 Pro, iOS 15.6, WiFi.
Device with PostHog not working: iPhone SE (3rd gen), iOS 16.2, WiFi.

Both tests were done with PostHog SDK v3.1.1, build with Xcode 14.2.

Can it be an issue with Gzip on iOS 16 or something else making the request bad?

[marandaneto]

@bddq #104
After this PR we'd have better logging, not sure, gzip is wrapped in a try-catch, so it'd throw and return early instead of calling the API and returning 400.
Let me get this merged, so you can test and check the logs.

I'll try to create an emulator using iPhone SE (3rd gen), iOS 16.2, WiFi

[marandaneto]

https://github.com/PostHog/posthog-ios/releases/tag/3.1.2
If you're using GH directly, please test it, if you're using Cocoapods, it'll take a few minutes.

[bddq]

I got it. Logs are now popping in Xcode console with 3.1.2 version.

You have an issue with the send_at value.
The toISO8601String(_) currently returns "2024-02-09T10:32:21.671 AMZ" value for my device.
This value seems not to be supported by your server.

Why in your DateUtils you are not using an ISO8601DateFormatter?

[bddq]

@marandaneto my device have 12-hour time format, so the date formatter is adding AM before Z. That's why.
I definitely advise you to use the ISO8601DateFormatter if it fits your need.

[marandaneto]

oh damn, let me check this @bddq thanks!

[marandaneto]

@bddq I managed to create an emulator and simulate the issue.
The string is always generated correctly.
Either without any changes, with the changes here, or this suggestion.
All of them were deterministic being 12h clock or 24h clock, the result was never including the AM.
Would you be able to run a test on your device and test it out if any of those has a different result for you?

[marandaneto]

Thanks @bddq for debugging with me.
https://github.com/PostHog/posthog-ios/releases/tag/3.1.3