"illegal Access" but there's no access at that line?

I should mention this code used to work (it worked for about 9 months without changes) until a recent update on Fenix 7.

What are you passing to the Background.exit() call?

Did you check the link?

Line 91:

            Background.exit({
                PROP_ERROR_MSG => msgLoginError(responseCode)
            });

PROP_ERROR_MSG is  string https://github.com/osa1/Dextrack/blob/f2a43d9f97bd4057ad53cd0ac868b39175745159/source/Props.mc#L14

`msgLoginError` returns a string: github.com/.../Consts.mc

In this case, the issue is that your app tried to invoke a symbol that is unavailable to the background process. No, it's not the best error message in the world.

Specifically, msgLoginError() is called by the background process, but that function isn't available in the background process. If you add the :background annotation to msgLoginError(), that should resolve your problem.

Note that all global variables are available to the background process (regardless of the :background annotation), but the same is not true for global functions.

https://developer.garmin.com/connect-iq/core-topics/backgrounding/

Also note that if you build with a type-check level of 2 (informative) or higher, you do a get a warning about msgLoginError on the Background.exit line (yeah technically it's not the same line, but the compiler just refers to the line that the statement starts on).

value 'msgLoginError' not available in all function scopes.

Also not the best error message in the world.

Unfortunately:

- the default type-check level is 1 (gradual)

- if you do use level 2 (informative) or higher, your specific project generates a huge amount of warnings, which would make it hard to isolate any of the warnings which actually point to issues

- the compiler seems to also (incorrectly?) warn about global consts/vars not being available in all function scopes (which contradicts the fact that global vars are always available to the background process - seems that the compiler doesn't know this)

9938694 said:

I should mention this code used to work (it worked for about 9 months without changes) until a recent update on Fenix 7.

Just a guess, but it could be that the update is now causing the code in question to run (due to receiving a non-200 result from makeWebRequest), but in the past that code never (or rarely) ran (due to makeWebRequest usually returning 200).