Skip to content

Conversation

@dustinbyrne
Copy link
Contributor

@dustinbyrne dustinbyrne commented Oct 24, 2025

💡 Motivation and Context

groupProperties is typed incorrectly in many cases.

This PR changes many instances of groupProperties: Map<String, String> to groupProperties: Map<String, Map<String, Any?>>

Similarly, many instances of userProperties have changed from Map<String, String> to Map<String, Any?> to match other SDKs.

This changes the shape of interfaces both in core and server-side libraries. This is a major version bump for both.

Resolves #310

💚 How did you test it?

Existing tests are updated

📝 Checklist

  • I reviewed the submitted code.
  • I added tests to verify the changes.
  • I updated the docs if needed.
  • No breaking change or entry added to the changelog.

@dustinbyrne dustinbyrne force-pushed the fix!/group-properties-structure branch from 99f940f to dd70e0e Compare October 28, 2025 18:44
@dustinbyrne dustinbyrne marked this pull request as ready for review October 29, 2025 21:17
@dustinbyrne dustinbyrne requested a review from a team as a code owner October 29, 2025 21:17
@dustinbyrne dustinbyrne moved this to In Review in Feature Flags Oct 29, 2025
groups: Map<String, String>?,
personProperties: Map<String, String>?,
groupProperties: Map<String, String>?,
personProperties: Map<String, Any?>?,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will this break the public API if someone declare and pass a Map<String, String>? should we raise a major?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is technically a major version bump in both packages. Hopefully this should be the last for a while.

groups: Map<String, String>?,
personProperties: Map<String, String>?,
groupProperties: Map<String, String>?,
personProperties: Map<String, Any?>?,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we prob should normalize all params with Any since non-serialized values can break serialization (confirm if GSON does this automatically?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GSON should be able to do this automatically but I'll include a test to verify

Copy link
Contributor Author

@dustinbyrne dustinbyrne Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

886d3a2

Does this address your concerns? I'd started looking at normalizing into primitive JSON types, but it seems GSON's default behavior may suffice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably yes, we do this on iOS https://github.com/PostHog/posthog-ios/blob/ba5dd65d2341ab8ea1949f072594ef67c490af3a/PostHog/Utils/DictUtils.swift#L10
if GSON behaves the same way, we are good.
It's important that GSON either stringifies any non-serializable object or just does not set it, rather than failing the serialization.
I'd suggest using a different type of object, which is not serializable eg a Context, Activity, View classes in Android, I suspect it might break the serialization but i am not 100% sure

@marandaneto marandaneto requested a review from a team November 3, 2025 17:01
@dustinbyrne dustinbyrne force-pushed the fix!/group-properties-structure branch from 696b74d to 3bb5b82 Compare November 4, 2025 00:29
@dustinbyrne dustinbyrne force-pushed the fix!/group-properties-structure branch from 3bb5b82 to 886d3a2 Compare November 4, 2025 00:35
@github-project-automation github-project-automation bot moved this from In Review to Approved in Feature Flags Nov 4, 2025
This allows properties to be safely deserialized without raising
exceptions. If an exception is raised while deserializing a property,
the property will simply be ignored and an error logged.
@dustinbyrne dustinbyrne merged commit 06dd8ae into main Nov 4, 2025
12 checks passed
@github-project-automation github-project-automation bot moved this from Approved to Done in Feature Flags Nov 4, 2025
@dustinbyrne dustinbyrne deleted the fix!/group-properties-structure branch November 4, 2025 19:13
@github-actions
Copy link

github-actions bot commented Nov 4, 2025

Fails
🚫 Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please add an entry to the appropriate changelog:

  • posthog/CHANGELOG.md (core module)
  • posthog-android/CHANGELOG.md (android module)
  • posthog-server/CHANGELOG.md (server module)

Make sure the entry includes this PR's number.
Example:

## Next
- Correctly type user and group properties ([#312](https://github.com/PostHog/posthog-android/pull/312))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against 5f6f11a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

fix(server): groupProperties is typed incorrectly

4 participants