search

3lvis / Networking

Swift HTTP Networking with stubbing and caching support
MIT License
1.36k stars 112 forks source link

Facing a strange crash time to time #260

Closed mkll closed 4 years ago

mkll commented 4 years ago

Hi @3lvis ,

I use Networking in an app that is currently under active development, so I run it in the simulator several dozen times a day. 1-2 times a day, the application crashes in the same place for no apparent reason:

Fatal error: Couldn't get destination URL for path: /api/v1/winery/ and cacheName: nil:
file /Users/mkII/Development/iOS/2nd-party/Vinilink/Pods/Networking/Sources/Networking+Private.swift, line 450

I tried to find out exactly which path is formed in those cases when there is no crash, and set a breakpoint. Here is the result:

Printing description of destinationURL:

file:///Users/mkII/Library/Developer/CoreSimulator/Devices/41288A44-998F-4CEA-
90E0-E2A1E1B2052F/data/Containers/Data/Application/6A9EDC90-81EC-47B0-BE4F-
DE69CA55CAAF/Library/Caches/com.3lvis.networking/https:--pro.vinilink.ch-api-v1-
winery-

Hmm, nothing special. Slashes are simply replaced by hyphens. It's ok.

I would like to clarify a few points for myself:

  1. Is it normal that Networking deals with the cache, even though I am instantiating it in ephemeral mode, i.e.: let networking = Networking(baseURL: baseUrl, configuration: .ephemeral)

  2. Is the fatalError really necessary in this place? It relates to deleting data from the cache. Well, really, it's just a cache. iOS will remove it itself if it needs. Is it necessary to crash the app just because the cache path could not be composed? It's especially sad to get a cache-related crash when you don't use the cache at all.

  3. Is it possible to completely disable any deal with the disk cache in ephemeral mode? May I, say, override the corresponding method calls?

Screenshot 2020-07-08 at 00 17 15

Thanks.

3lvis commented 4 years ago

Hello @mkll!

1.- I think your logic makes sense, somehow the URL session configuration should have been connected to the way caching is handled in Networking. Sadly, it wasn't done that way, instead caching is handled at the call level. Whenever you make a Networking call you can decide the caching level, the default is none.

If I were to make the change now of connecting URL session configuration with how caching is handled I'm worried it might lead to inconsistent behavior, where some people using ephemeral tried to do caching here and there and it wouldn't work.

If caching is none by default and you aren't using any caching I'm surprised why this crash is even happening. Either way, it's something we need to fix.

2.- The fatalError is not necessary. I'll remove it. If we can't construct the URL in this method we should just escape instead of crashing.

3.- My answer here is similar to the 1st one, even though your logic makes sense I'm afraid it could cause unwanted behavior.

mkll commented 4 years ago

@3lvis thanks for the clarification. Imagine how surprised I was when I saw this crash for the first time. Whaaat? Caaache? But how? :) As for me, removing fatalError seems to be enough to eliminate negative impact. It's just an overkill here.

3lvis commented 4 years ago

Fix published in 5.0.3, thanks!

https://github.com/3lvis/Networking/releases/tag/5.0.3

Finding this project helpful? Consider supporting further development and support by becoming a sponsor:
👉 https://github.com/sponsors/3lvis