v2 Model API: `POST /api/v2/models/grouplocations/search` returns HTTP 500 (lazy-nav serialized after DbContext disposed)

[sircris]

Description

The generic v2 Model API search for GroupLocation returns HTTP 500 whenever it materializes full GroupLocation entities. The HTTP body is the generic {"Message":"An error has occurred."}, but the ExceptionLog shows serialization fails because a lazy-loaded navigation collection (GroupLocationScheduleConfigs) is accessed after the EF ObjectContext has already been disposed.

This appears to be framework-level — a stock entity and stock navigation property, no custom code — and reproduces with any GroupLocation row. Other entities' search endpoints return normally; GroupLocation is the one that defer-loads a navigation collection during serialization.

A client-side workaround exists (projecting scalar fields via select), so this isn't urgent. Flagging it because the default search (no select) is unusable for GroupLocation, and the same failure mode could affect any entity whose navigation collection lazy-loads during serialization.

The Reproduced the problem on a fresh install or on the demo site checkbox below about the fresh installation is not fresh as of today, but the install was done from scratch.

Actual Behavior

HTTP 500, body {"Message":"An error has occurred."}. The ExceptionLog records two chained exceptions:

Newtonsoft.Json.JsonSerializationException:
  Error getting value from 'GroupLocationScheduleConfigs' on
  'System.Data.Entity.DynamicProxies.GroupLocation_<proxy>'.
    at Newtonsoft.Json.Serialization.DynamicValueProvider.GetValue(Object target)
    at ...JsonSerializerInternalWriter.SerializeObject(...)
    at ...JsonSerializerInternalWriter.SerializeList(...)

Inner — System.ObjectDisposedException:
  The ObjectContext instance has been disposed and can no longer be used for
  operations that require a connection.
    at System.Data.Entity.Core.Objects.ObjectContext.get_Connection()
    at ...EntityCollection`1.Load(...)
    at ...RelatedEnd.DeferredLoad()
    at ...LazyLoadBehavior.LoadProperty[TItem](...)

Likely cause: search returns EF dynamic-proxy entities with lazy loading enabled; during serialization Newtonsoft reads GroupLocationScheduleConfigs, triggering a deferred load after the request's DbContext has been disposed.

Workaround (returns 200): project scalar fields only —

{ "select": "new(Id, GroupId, LocationId, GroupLocationTypeValueId)", "limit": 50 }

Possible fix: disable lazy loading / proxy creation before serializing search results in the generic model controller (or eager-load + detach the graph).

Expected Behavior

HTTP 200 with the standard envelope, identical to every other entity's v2 model search:

{ "count": 1, "items": [ /* GroupLocation objects */ ] }

Steps to Reproduce

1. Grant a REST API key's role read access to the GroupLocations v2 controller's search action (or use an admin session on the demo site).
2. POST the search with no projection:

curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST "https://<your-rock>/api/v2/models/grouplocations/search" \
  -H "Authorization-Token: <api-key>" \
  -H "Content-Type: application/json" \
  -d '{ "limit": 1 }'

3. Observe HTTP 500. An empty body {} also reproduces. GetItem / GetAttributeValues on the same controller are unaffected.

Reproduces: 100%

Issue Confirmation

• Perform a search on the Github Issues to see if your bug is already reported.
• Reproduced the problem on a fresh install or on the demo site.

Rock Version

Rock McKinley 18.2 (18.2.4)

Client Culture Setting

en-US

[cabal95]

@sircris This sounds familiar (as in, I feel like this was reported and fixed but can't find the issue) so I wanted to verify that you indeed did test this on the demo site and verified it still has the problem on Rock 19.2?

[sircris]

Thank you very much for the quick reply. I promise that I did search for the issue before I posted it. Not a blocker, but wanted to bring it your attention.

I actual discovered it because we are trying to migrate our APIs from Rock API v1 and API v2.

[cabal95]

Okay thanks for confirming. No worries, just sounded very familiar. 😄

[cabal95]

@sircris This will be fixed in 19.4. The new v2 API endpoints are designed to not include navigation properties automatically for a few reasons. One of them being this error. However the GroupLocationScheduleConfig object didn't match the typical "navigation property" pattern so the exclude logic was not correctly excluding it. This has been fixed.

Note: You can still access the navigation property with a select mapping statement, it just won't be included automatically when the full object is returned.