Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on nil property #2907

Closed
yonaskolb opened this issue Mar 29, 2023 · 2 comments · Fixed by #2908
Closed

Crash on nil property #2907

yonaskolb opened this issue Mar 29, 2023 · 2 comments · Fixed by #2908
Labels
bug Generally incorrect behavior needs investigation

Comments

@yonaskolb
Copy link
Contributor

yonaskolb commented Mar 29, 2023

Summary

We've been seeing a crash after using the generated inits and then accessing a nil property. It occurs within DataDict.swift
The crash is on line 78 but I believe the issue is from line 91, where an AnyHashable? is unwrapped unsuccessfully and is then passed along as AnyHashable with a value of nil on line 95. I don't know if it's an issue in the inits not managing nil values properly or a swift dynamic casting issue with the functions here.

Screenshot 2023-03-29 at 3 07 06 pm

lldb on line 95:

(lldb) po data
▿ AnyHashable(nil)
  - value : nil

Here is the full generated model we're trying to initialise. A bunch of properties have been removed to simplify it:

public struct AppPageHeroSectionData: ShopAPI.SelectionSet, Fragment {
  public static var fragmentDefinition: StaticString { """
    fragment AppPageHeroSectionData on AppPageHeroSection {
      __typename
      id
      personalizedMessaging {
        __typename
        id
        title
      }
    }
    """ }

  public let __data: DataDict
  public init(_dataDict: DataDict) { __data = _dataDict }

  public static var __parentType: ApolloAPI.ParentType { ShopAPI.Objects.AppPageHeroSection }
  public static var __selections: [ApolloAPI.Selection] { [
    .field("__typename", String.self),
    .field("id", ShopAPI.ID.self),
    .field("personalizedMessaging", PersonalizedMessaging?.self),
  ] }

  public var id: ShopAPI.ID { __data["id"] }
  public var personalizedMessaging: PersonalizedMessaging? { __data["personalizedMessaging"] }

  public init(
    id: ShopAPI.ID,
    personalizedMessaging: PersonalizedMessaging? = nil
  ) {
    self.init(_dataDict: DataDict(data: [
      "__typename": ShopAPI.Objects.AppPageHeroSection.typename,
      "id": id,
      "personalizedMessaging": personalizedMessaging._fieldData,
      "__fulfilled": Set([
        ObjectIdentifier(Self.self)
      ])
    ]))
  }

  /// PersonalizedMessaging
  ///
  /// Parent Type: `PersonalizedMessagingTextBlock`
  public struct PersonalizedMessaging: ShopAPI.SelectionSet {
    public let __data: DataDict
    public init(_dataDict: DataDict) { __data = _dataDict }

    public static var __parentType: ApolloAPI.ParentType { ShopAPI.Objects.PersonalizedMessagingTextBlock }
    public static var __selections: [ApolloAPI.Selection] { [
      .field("__typename", String.self),
      .field("id", ShopAPI.ID.self),
      .field("title", String.self),
    ] }

    public var id: ShopAPI.ID { __data["id"] }
    public var title: String { __data["title"] }

    public init(
      id: ShopAPI.ID,
      title: String
    ) {
      self.init(_dataDict: DataDict(data: [
        "__typename": ShopAPI.Objects.PersonalizedMessagingTextBlock.typename,
        "id": id,
        "title": title,
        "__fulfilled": Set([
          ObjectIdentifier(Self.self)
        ])
      ]))
    }
  }
}

Version

Apollo: 1.1.0-beta
Xcode: 14.2
Swift: 5.7.2
iOS: 16.2

Steps to reproduce the behavior

Create a SelectionSet that has an optional SelectionSet property, initialise that to nil and access it.

let section = AppPageHeroSectionData(
  id: "1",
  personalizedMessaging: nil
)
let message = section.personalizedMessaging // expect nil but it crashes

Logs

No response

Anything else?

This may be related to the following 2 issues:

@yonaskolb yonaskolb added bug Generally incorrect behavior needs investigation labels Mar 29, 2023
@AnthonyMDev
Copy link
Contributor

Thanks for this awesome report and your PR! I'll be looking into this today and let you know what I come up with.

@AnthonyMDev
Copy link
Contributor

This is now fixed on main and will be included in the 1.1 GA release! Thanks so much @yonaskolb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Generally incorrect behavior needs investigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants