Demo code on atsign.dev no longer compiles cleanly

[cconstab]

Describe the bug Error when following the instructions on atsign.dev

To Reproduce Steps to reproduce the behavior:

1. First go to https://atsign.dev/docs/get-started/tryatplatform/
2. When running the app compile time errors (tested on windows)

C:\Users\colin\test\testme>flutter run
Using hardware rendering with device Android SDK built for x86. If you notice graphics artifacts, consider enabling software rendering with "--enable-software-rendering".
Launching lib\main.dart on Android SDK built for x86 in debug mode...
/C:/tools/flutter/.pub-cache/hosted/pub.dartlang.org/at_client-3.0.13/lib/src/client/remote_secondary.dart:83:20: Error: A value of type 'int?' can't be assigned to a variable of type 'int' because 'int?' is nullable and 'int' isn't.
      ..commitId = lastSyncedId
                   ^


FAILURE: Build failed with an exception.

* Where:
Script 'C:\tools\flutter\packages\flutter_tools\gradle\flutter.gradle' line: 1102

* What went wrong:
Execution failed for task ':app:compileFlutterBuildDebug'.
> Process 'command 'C:\tools\flutter\bin\flutter.bat'' finished with non-zero exit value 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 36s
Running Gradle task 'assembleDebug'...                             37.0s
Exception: Gradle task assembleDebug failed with exit code 1

C:\Users\colin\test\testme>

Expected behavior The demo should always run and be tested when we push new code (lets automate this !)

Screenshots See above

Smartphone (please complete the following information):

• Tested on Windows but this will be the same across all platforms is my guess

Were you using an @‎application when the bug was found? -demo app

Additional context PLease use this and the snackbar sender as a simple test of client changes!

[cconstab]

I think maybe we canary builds on the client side.. Thoughts welcome

[gkc]

Ideally I think we would run a straight compile only (because we won't have a device connected) on this demo (and any other 'interesting' code) every time there is a merge to trunk of a PR in the at_client_sdk, at_tools or at_libraries repos

I don't know if cross-server hooks like that are possible, so a good alternative might be to compile this demo periodically - maybe a few times per day.

I was curious about this issue because while both at_client and at_commons packages have changed recently, the latest packages are consistent with each other, and the previous versions are consistent with each other also - i.e. in theory per my understanding this problem should not have happened ... so I looked into it a bit more deeply, and I think it's a problem with how flutter pub get works

Snackbar has this in its pubspec.yaml

  at_client_mobile: ^3.0.3
  at_utils: ^3.0.0

Here's what .packages has after first running at_app create and flutter run. I've only included the subset of packages relevant to this conversation

gkc2019:snackz gary$ grep --color=none at_ .packages
at_client:file:/some/path/at_client-3.0.13/lib/
at_client_mobile:file:/some/path/at_client_mobile-3.1.9/lib/
at_commons:file:/some/path/at_commons-3.0.10/lib/
at_lookup:file:/some/path/at_lookup-3.0.15/lib/
at_utils:file:/some/path/at_utils-3.0.7/lib/

However if I change the dependency toat_client_mobile: ^3.1.10 then when I remove .packages and do another flutter pub get, everything resolves just fine, and the app builds and successfully runs on my iphone.

Here's what .packages has now:

at_client:file:///Users/[...]/at_client-3.0.14/lib/ <== up, from 3.0.13 
at_client_mobile:file:/some/path/at_client_mobile-3.1.10/lib/ <== up, from 3.1.9
at_commons:file:/some/path/at_commons-3.0.9/lib/ <== down, from 3.0.10
at_lookup:file:/some/path/at_lookup-3.0.14/lib/ <== down, from 3.0.15 
at_utils:file:/some/path/at_utils-3.0.6/lib/ <== down, from 3.0.7 

In summary - when we start with '^3.0.3' for at_client_mobile, dependencies don't resolve correctly, even though the latest version after 3.0.3 is 3.1.10; but when we start with '^3.1.10' for at_client mobile, the dependencies all do resolve correctly. (Another point to note if anyone else picks this up to investigate more, is that at_client_mobile is restricting to specific known versions at_client: 3.0.14 at_lookup: 3.0.14 at_commons: 3.0.9 - which is fine, as we know those versions work together, and ultimately those are indeed the versions we end up with)

Not sure what to do about that. Maybe configure dependabot to nag us to update pubspec.yaml in important packages (like the snackbar demo) when new versions of dependencies are available? @XavierChanth wdyt?

[cconstab]

So upgraded flutter to latest version and everything works just fine now...

Very odd as I cannot find any notes covering this issue..

Will look into a job to build this every so often and keep flutter etc at the latest version

Will raise a ticket for that and close this ticket...

[gkc]

That's just plain weird.

[XavierChanth]

Not sure what to do about that. Maybe configure dependabot to nag us to update pubspec.yaml in important packages (like the snackbar demo) when new versions of dependencies are available? @XavierChanth wdyt?

This has been in the back of my mind with at_app, I'd like to automate as much maintenance work with the repository as possible. All verification and testing of the cli and generated apps should eventually be automated, but I still have plenty of work to do before it gets there. I plan to resume my progress on this goal in May.

[ksanty]

@XavierChanth is this an arch discussion item?

[gkc]

It's related to our overall testing approach, particularly automated retesting when deiendencues change and yes we need to discuss it

[XavierChanth]

Closing, as this demo code no longer exists.