We have observed the following panic a few times in production:

Got a panic: panicked at /builds/[...]/vendor/deps/objc2-network-extension-0.3.1/src/generated/mod.rs:9479:5:
unexpected NULL returned from -[NWAddressEndpoint hostname]
0: __mh_execute_header
1: __mh_execute_header
2: __mh_execute_header
3: __mh_execute_header
4: __mh_execute_header
5: __mh_execute_header
6: __mh_execute_header
7: __mh_execute_header
8: __mh_execute_header
9: __mh_execute_header
10: __mh_execute_header
11: __mh_execute_header
12: __mh_execute_header
13: __mh_execute_header
14: __mh_execute_header
15: __mh_execute_header
16: __mh_execute_header
17: __mh_execute_header
18: __mh_execute_header
19: __mh_execute_header
20: __mh_execute_header
21: __mh_execute_header
22: __mh_execute_header
23: __mh_execute_header
24: __mh_execute_header
25: __mh_execute_header
26: __mh_execute_header
27: __pthread_cond_wait

(super duper useful backtrace, yay)

From the two separate cases I easily have access to at the moment, both machines are under macOS 15.6.1.

We call [NWHostEndpoint hostname] on the endpoints given to us from the NetworkExtension FilterDataProvider API as part of the socket flows after downcasting them from NWEndpoint to NWHostEndpoint, so we don't really have control over the values themselves nor how their are built. This seems like a macOS or bindings issue to me.

Regarding the bindings lead, [NWHostEndpoint hostname] is generated in objc2 with a non-null return type and in the SDK, the properties also don't have the nullable attribute. The SDK headers also use the NS_ASSUME_NONNULL_BEGIN and NS_ASSUME_NONNULL_END macros to surround the definitions, but I don't know what it really means or does. When looking at nw_endpoint_get_hostname that it should only wrap if I understand correctly, it clearly states that it:

Returns the hostname string for the endpoint, or NULL
if the endpoint is not of type nw_endpoint_type_host.

and considering that it:

Retrieves the hostname string for a network endpoint with
the type nw_endpoint_type_host or nw_endpoint_type_url.

it should mean that the NULL case really is reachable, which should in turn imply that the Obj-C wrapper headers are wrong in this aspect, if not both even as I don't see _Nullable for nw_endpoint_get_hostname either, right?

If so, what do you think would be the best course of action for fixing this? Even though I don't have much hope for it, I would first try reporting this to Apple, but then it would mean skipping the class in the generation and then manually redefining it with the fixed return type?

Also, interestingly, NWHostEndpoint seems to have the NWAddressEndpoint class name at runtime for some obscure reason, because ClassType::class is used on the receiver when generating the panic from what I can see in the msg_send! implementation details. The only place I see the latter is in Network.tbd, but I don't really know what it means because NWHostEndpoint is also there. It does mention nw_endpoint_type_address, but I don't know why it wouldn't be reflected in a proper class available in the SDK as per the usual 🤷