The service did not respond to the start or control request in a timely fashion

Gitea version: 1.14.0-rc2 (gitea-1.14.0-rc2-windows-4.0-amd64.exe download)
Git version: 2.7
Operating system: Windows Server 2008 R2
Database: SQLite

Gitea does not start up when running as a Windows service.  "The service did not respond to the start or control request in a timely fashion" .  I have set the registry option ServicesPipeTimeout to 240000 which is 4 minutes.  The gitea.exe process can be seen in the task manager, but it eventually dies.
Running gitea web, it starts up just fine.
Version 1.13.6 starts up fine as a service on the same machine.
gitea.log.txt
app.ini.txt

To avoid duplicating issues, I will append to this ticket.
A coworker and I are also encountering this same issue in pretty much the exact same manner as @markburgessstl here and #15134. We attempted to follow the recommended "gitea migrate" commandlet metioned in #15134 but to no avail.
Log:
2021/03/25 12:35:54 ...dules/setting/log.go:333:newLogService() [I] Gitea Log Mode: File(File:debug)
2021/03/25 12:35:54 ...dules/setting/log.go:250:generateNamedLogger() [I] Router Log: Console(console:debug)
2021/03/25 12:35:54 ...les/setting/cache.go:73:newCacheService() [I] Cache Service Enabled
2021/03/25 12:35:54 ...les/setting/cache.go:88:newCacheService() [I] Last Commit Cache Service Enabled
2021/03/25 12:35:54 ...s/setting/session.go:77:newSessionService() [I] Session Service Enabled
2021/03/25 12:35:54 ...es/setting/mailer.go:109:newMailService() [I] Mail Service Enabled
2021/03/25 12:35:54 ...es/setting/mailer.go:131:newNotifyMailService() [I] Notify Mail Service Enabled
2021/03/25 12:35:54 ...s/storage/storage.go:151:initAttachments() [I] Initialising Attachment storage with type:
2021/03/25 12:35:54 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:\Gitea\data\attachments
2021/03/25 12:35:54 ...s/storage/storage.go:145:initAvatars() [I] Initialising Avatar storage with type:
2021/03/25 12:35:54 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:\Gitea\data\avatars
2021/03/25 12:35:54 ...s/storage/storage.go:163:initRepoAvatars() [I] Initialising Repository Avatar storage with type:
2021/03/25 12:35:54 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:\Gitea\data\repo-avatars
2021/03/25 12:35:54 ...s/storage/storage.go:157:initLFS() [I] Initialising LFS storage with type:
2021/03/25 12:35:54 ...les/storage/local.go:47:NewLocalStorage() [I] Creating new Local Storage at C:/Gitea/data/lfs
2021/03/25 12:35:54 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: push_update Starting
2021/03/25 12:35:54 ...ue/queue_bytefifo.go:96:Run() [D] level: push_update-level Starting
2021/03/25 12:35:54 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: mail Starting
2021/03/25 12:35:54 ...ue/queue_bytefifo.go:96:Run() [D] level: mail-level Starting
2021/03/25 12:35:54 routers/init.go:150:GlobalInit() [I] SQLite3 Supported
2021/03/25 12:35:54 routers/init.go:68:initDBEngine() [I] Beginning ORM engine initialization.
2021/03/25 12:35:54 routers/init.go:75:initDBEngine() [I] ORM engine initialization attempt #1/10...
2021/03/25 12:35:54 ...ueue_disk_channel.go:137:Run() [D] PersistableChannelQueue: notification-service Starting
2021/03/25 12:35:54 ...rm/session_schema.go:25:Ping() [I] PING DATABASE postgres
2021/03/25 12:35:54 ...ue/queue_bytefifo.go:96:Run() [D] level: notification-service-level Starting
2021/03/25 12:35:55 ...rm/session_schema.go:360:Sync2() [W] Table user Column max_repo_creation db default is '-1', struct default is -1
2021/03/25 12:35:56 ...rm/session_schema.go:431:Sync2() [W] Table session has column created_unix but struct has not related field
2021/03/25 12:35:56 routers/init.go:155:GlobalInit() [I] ORM engine initialization successful!
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: update_mirrors
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: repo_health_check
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: check_repo_stats
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: archive_cleanup
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: sync_external_users
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: deleted_branches_cleanup
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: update_migration_poster_id
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: cleanup_hook_task_table
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_inactive_accounts
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_repo_archives
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: git_gc_repos
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: resync_all_sshkeys
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: resync_all_sshprincipals
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: resync_all_hooks
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: reinit_missing_repos
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_missing_repos
2021/03/25 12:35:56 ...odules/cron/tasks.go:120:RegisterTask() [D] Registering task: delete_generated_repository_avatars
2021/03/25 12:35:56 ...i/websspi_windows.go:87:New() [I] Credential handle expiry: 2185-07-20 12:34:33.712009116 -0600 CST
2021/03/25 12:35:56 ...er/issues/indexer.go:142:func2() [I] PID 764: Initializing Issue Indexer: bleve
2021/03/25 12:35:56 ...er/issues/indexer.go:221:func3() [I] Issue Indexer Initialization took 109.3727ms
2021/03/25 12:35:56 ...xer/stats/indexer.go:84:populateRepoIndexer() [I] Done (re)populating the repo stats indexer with existing repositories
2021/03/25 12:35:56 ...ue/queue_bytefifo.go:96:Run() [D] level: issue_indexer Starting
2021/03/25 12:35:56 ...ue/queue_bytefifo.go:96:Run() [D] unique-level: repo_stats_update-level Starting
2021/03/25 12:35:56 ...ue/queue_bytefifo.go:96:Run() [D] unique-level: pr_patch_checker-level Starting
2021/03/25 12:35:56 ...ue/queue_bytefifo.go:96:Run() [D] level: task-level Starting
2021/03/25 12:35:57 cmd/web.go:189:listen() [I] Listen: http://<IP_ADDRESS>:3000
2021/03/25 12:35:57 cmd/web.go:192:listen() [I] LFS server enabled
2021/03/25 12:35:57 ...s/graceful/server.go:55:NewServer() [I] Starting new Web server: tcp:<IP_ADDRESS>:3000 on PID: 764
2021/03/25 12:35:57 ...s/graceful/server.go:66:func1() [D] Starting server on tcp:<IP_ADDRESS>:3000 (PID: 764)

This is running on a Windows Server 2016 machine. We are trying to fix our original problem see in #14167.

hmm... This is very strange... just testing on linux here I can't see a reason why the SVC manager isn't being informed of a successful startup correctly.
I guess it might be reasonable to set:
[server]
...
STARTUP_TIMEOUT=30s

and see if that improves things - but it doesn't look like there is a significant delay in the startup so it may simply delay the problem for 30 seconds.
Are you able to compile gitea? If so it may be reasonable to add some logging in to the SVC handler.

hmm... This is very strange... just testing on linux here I can't see a reason why the SVC manager isn't being informed of a successful startup correctly.
I guess it might be reasonable to set:
[server]
...
STARTUP_TIMEOUT=30s

and see if that improves things - but it doesn't look like there is a significant delay in the startup so it may simply delay the problem for 30 seconds.
Are you able to compile gitea? If so it may be reasonable to add some logging in to the SVC handler.

I tried the STARTUP_TIMEOUT but it didn't make any difference.
Unfortunately I can't compile Gitea on Windows

Fine:
https://eldritchkitty.com/~andrew/gitea-915748a93-windows-4.0-amd64.exe
Is a build of:
https://github.com/go-gitea/gitea/compare/release/v1.14...zeripath:logging-for-15159?expand=1
Using:
make release-windows
It should match the detached signature:
https://eldritchkitty.com/~andrew/gitea-915748a93-windows-4.0-amd64.exe.asc
which  I will copy below:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE0s922pXyAemQFTKrPN50Yx8Tp0gFAmBdAwIACgkQPN50Yx8T
p0jOgRAAgqoYelsheDd+J7xSv7x6yU9V3SRjl1x6c5GEIDb3xD4c+JroWVXUjSHx
mF34Wt6+rWZVopSmja6J8juE4VgDgwwcisaEBiq0JkXFaZIMgZKtr6TM95hmwcCZ
7rd2pBcg0JxMPcSRKaN0EJ2IswKZtru7kV+FtdxGK2SnmcG6fsAggL+9CedTMlgI
4nHVnWaXzLQNrE/w36hhF65QmLQDTzUla7DXWb8SKEhX9cEGo1ON4gIvk29nSK/e
2GvWYMZU+T3p/q7EDQXLa5NghBdt+L56bfPEkYTA2cJhCu7Z65EHfr9ylENcDDAB
PjCK7OUf/oZwhOd3Ty0ovYctOaKEcFMWe1TlaSHYT45XixNpYbIVOZNXPsvvt3HY
HNcf8Cqqn8sxCkkOCpGRrs9HS+COT52kTYHrCy8eqVR79QBvbNlbPueh/MAKY4Cg
7kebShNfXmsDH2d/2Ni+nsW61JOT8Dg+gK8gweXPJCKcjOIA2LT2uB5Fr3SyREgF
WknzJjD4EyiTegqo9IphtKGoGx83HUUkvHqZJ+oPYjP8jeXYlTxkOn6MHEx+6nMD
GEISrSx2uuIBfV67dVVRFgvC2fdFxlgh+OB4YmZQ2mIA1Ebl/O+89Fga0tK/8t6m
CMDzoO6rmmY5a1HnRmpe8a+KHViLK8J+P92SH99nhOTqE5NENcQ=
=e9GE
-----END PGP SIGNATURE-----

Which is signed by my gpg key attached this account (and elsewhere) and can be obtained from:
https://github.com/zeripath.gpg
If you do not wish to check the signature. The file should have the sha256sum:
63f24650b75a9ef8365c5d238b663d5551fe10b053b765b476ca1e557fb0a44d

Fine:
https://eldritchkitty.com/~andrew/gitea-915748a93-windows-4.0-amd64.exe
Is a build of:
https://github.com/go-gitea/gitea/compare/release/v1.14...zeripath:logging-for-15159?expand=1
Using:
make release-windows
It should match the detached signature:
https://eldritchkitty.com/~andrew/gitea-915748a93-windows-4.0-amd64.exe.asc
which I will copy below:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE0s922pXyAemQFTKrPN50Yx8Tp0gFAmBdAwIACgkQPN50Yx8T
p0jOgRAAgqoYelsheDd+J7xSv7x6yU9V3SRjl1x6c5GEIDb3xD4c+JroWVXUjSHx
mF34Wt6+rWZVopSmja6J8juE4VgDgwwcisaEBiq0JkXFaZIMgZKtr6TM95hmwcCZ
7rd2pBcg0JxMPcSRKaN0EJ2IswKZtru7kV+FtdxGK2SnmcG6fsAggL+9CedTMlgI
4nHVnWaXzLQNrE/w36hhF65QmLQDTzUla7DXWb8SKEhX9cEGo1ON4gIvk29nSK/e
2GvWYMZU+T3p/q7EDQXLa5NghBdt+L56bfPEkYTA2cJhCu7Z65EHfr9ylENcDDAB
PjCK7OUf/oZwhOd3Ty0ovYctOaKEcFMWe1TlaSHYT45XixNpYbIVOZNXPsvvt3HY
HNcf8Cqqn8sxCkkOCpGRrs9HS+COT52kTYHrCy8eqVR79QBvbNlbPueh/MAKY4Cg
7kebShNfXmsDH2d/2Ni+nsW61JOT8Dg+gK8gweXPJCKcjOIA2LT2uB5Fr3SyREgF
WknzJjD4EyiTegqo9IphtKGoGx83HUUkvHqZJ+oPYjP8jeXYlTxkOn6MHEx+6nMD
GEISrSx2uuIBfV67dVVRFgvC2fdFxlgh+OB4YmZQ2mIA1Ebl/O+89Fga0tK/8t6m
CMDzoO6rmmY5a1HnRmpe8a+KHViLK8J+P92SH99nhOTqE5NENcQ=
=e9GE
-----END PGP SIGNATURE-----

Which is signed by my gpg key attached this account (and elsewhere) and can be obtained from:
https://github.com/zeripath.gpg
If you do not wish to check the signature. The file should have the sha256sum:
63f24650b75a9ef8365c5d238b663d5551fe10b053b765b476ca1e557fb0a44d

Fine:
https://eldritchkitty.com/~andrew/gitea-915748a93-windows-4.0-amd64.exe
Is a build of:
https://github.com/go-gitea/gitea/compare/release/v1.14...zeripath:logging-for-15159?expand=1
Using:
make release-windows
It should match the detached signature:
https://eldritchkitty.com/~andrew/gitea-915748a93-windows-4.0-amd64.exe.asc
which I will copy below:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE0s922pXyAemQFTKrPN50Yx8Tp0gFAmBdAwIACgkQPN50Yx8T
p0jOgRAAgqoYelsheDd+J7xSv7x6yU9V3SRjl1x6c5GEIDb3xD4c+JroWVXUjSHx
mF34Wt6+rWZVopSmja6J8juE4VgDgwwcisaEBiq0JkXFaZIMgZKtr6TM95hmwcCZ
7rd2pBcg0JxMPcSRKaN0EJ2IswKZtru7kV+FtdxGK2SnmcG6fsAggL+9CedTMlgI
4nHVnWaXzLQNrE/w36hhF65QmLQDTzUla7DXWb8SKEhX9cEGo1ON4gIvk29nSK/e
2GvWYMZU+T3p/q7EDQXLa5NghBdt+L56bfPEkYTA2cJhCu7Z65EHfr9ylENcDDAB
PjCK7OUf/oZwhOd3Ty0ovYctOaKEcFMWe1TlaSHYT45XixNpYbIVOZNXPsvvt3HY
HNcf8Cqqn8sxCkkOCpGRrs9HS+COT52kTYHrCy8eqVR79QBvbNlbPueh/MAKY4Cg
7kebShNfXmsDH2d/2Ni+nsW61JOT8Dg+gK8gweXPJCKcjOIA2LT2uB5Fr3SyREgF
WknzJjD4EyiTegqo9IphtKGoGx83HUUkvHqZJ+oPYjP8jeXYlTxkOn6MHEx+6nMD
GEISrSx2uuIBfV67dVVRFgvC2fdFxlgh+OB4YmZQ2mIA1Ebl/O+89Fga0tK/8t6m
CMDzoO6rmmY5a1HnRmpe8a+KHViLK8J+P92SH99nhOTqE5NENcQ=
=e9GE
-----END PGP SIGNATURE-----

Which is signed by my gpg key attached this account (and elsewhere) and can be obtained from:
https://github.com/zeripath.gpg
If you do not wish to check the signature. The file should have the sha256sum:
63f24650b75a9ef8365c5d238b663d5551fe10b053b765b476ca1e557fb0a44d

Awesome, thanks for the work. We will try this tomorrow morning and give you feedback (and logs) on what happens if there is no change.

zeripath, thank you for the special build.  I ran it this morning, and as expected it timed out after a few minutes.   The log is attached.
gitea.log.txt

Our log as well:
gitea.log

I can't see any log line saying starting SVC handler there and there should be 4 inform cleanups called but it looks like there's only two.
This is weird and I am suspicious that something has unhitched this functionality - which is great because I don't completely remember how I got it wired in in the first place and I can't test it myself.

Ok, no worries. For now, I can just start Gitea manually if needed since it runs fine from the command line (just not as a service). Let me know if you, or any other contributor/maintainer needs any more details from my side.

OK
lets try:
https://eldritchkitty.com/~andrew/gitea-e5e9c67a03f4-windows-4.0-amd64.exe
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE0s922pXyAemQFTKrPN50Yx8Tp0gFAmBiRqoACgkQPN50Yx8T
p0jaLg/+Lxorpz5s+U5Drtt1spCFm+6PwJWDn4sas07X8UWSr8Auw72zwh6t9tEe
shndgJgHqorI0J6bJrrXZDzYGWGZDg7TM3SJbWgrxQFKb2DoTwpn2QqlFaFntr4I
C/mOsSZbA/DIkOphaeDrKinXPI/CT0NWRMUYzJFynsT79pWLPYzMYXAheRNmIXyw
xp6ulZQdOOdI+DuobaiOEyAqH8lAmQ1T29jWOmVxqzUoOEf0DXwHKdvGIH3FtaVp
ws2mOlTeyzolASY3+Qt6z26SrpP60xFzrQdKouBapflaaLXL/2rEdQKUXgoY4nwB
8h5WqOJ5Vcz88aWfRM7YHmUMIG76IVZlMOj7xOH2rmWlEeUHDtB+Np+0PreUsgvu
M29Fx/kFdynHqlFMt3IJzgywSNIp2d3nHKLGtII6v+aH0uxbWqMISOmme0ySKf4L
ZLV+1iA863w5A5aCkDHxDzBNjUpgDIWkHoOJj3o2erqAyumQvzJFZ1PtTa3zswMj
1gwm/LNrKN1WOt3NqpVQriNEexxSjiNH2aaQkV81km6Z7m5tTPSPjVEoQp5IZoYm
wbtD45SjvXtZI5Z8hzeElR+NQWg/cLflS3qfSuBPrFVxBdD6M2+ilDnTJz+Sm/95
pNoHcfjbApN12pV+dV1c7UCBpIHFjhpk902EOJr9iOBidwEoRxY=
=9SVC
-----END PGP SIGNATURE-----

sha256sum:
fd9042e5b0359e742020ab4e70d2facd4b0c9169aaa479b70965693c6c49fd5c  gitea-e5e9c67a03f4-windows-4.0-amd64.exe

This adds some more logging

gitea.log
Here's my log.  I tried three time to start the service.
Windows thinks the service is "starting" or "START_PENDING"
Thank you!

Please could you set LOG_SQL=false in the [database] section of your app.ini . Logging SQL statements is way too noisy and irrelevant to this problem.
This time it looks like we're getting the inform cleanups but I'm not seeing the new logging statements I put in.
In particular I should see something like Graceful manager starting up logged at error level.

But...
I do see this:
2021/03/29 17:33:30 ...l/manager_windows.go:109:Execute() [I] sending running status
2021/03/29 17:33:30 ...l/manager_windows.go:117:Execute() [I] sent running status

That means that gitea does think it's telling the SVC host it's running.

Yes, it thinks that but that's not happening.
Let me know if you need more logs or anything else to help get to the bottom of it

@zeripath Here is our log file. We also had no luck with this exe, but thank you again for your work in helping solve this!
We are running Gitea on a Windows Server 2016 machine, just as a reminder.
gitea.log

agh! I think I've found the issue!

https://github.com/go-gitea/gitea/blob/f5b6dc9759e8077f76072dbb01586f9876ccafbf/modules/graceful/manager_windows.go#L76-L81
The IsInteractive should be IsWindowsService and should therefore be on line 81 !isInteractive

Excellent work, thank you very much for the PR!
To prevent this issue in the future, could we add a test to ensure the server will run as a service? I'm not a Go developer nor do I know your/the team's environment, so I don't know how feasible this would be. I know Github has Actions, so could it be done there?

We don't run tests on Windows - Windows isn't free - and I'm not certain of how we would test this reliably as in almost all testing scenarios you wouldn't actually have the thing attach to the SVC host anyway.
The particular bug is unlikely to be replicated in any case.
All I can say is that we need people to test the RCs like you have done, bear with us if we find problems, and help us with logging etc. This isn't that different from any other debugging situation.

Understandable.
I looked more into GitHub Actions as I was going to counter with that, but it doesn't yet allow services on Windows nor MacOS, only Linux. Regardless, thought I'd give it a shot!
Thanks for the clarification.


Add Lock capability to SmartThings platform

Description:
This PR adds functionality for Locks expressed through the SmartThings platform.
Locking/Unlocking is working great, however I'm not sure whether we should update the state straight away (faster UI feedback) or wait for the confirmation from SmartThings (removes false positives).
Also as mentioned in the referenced issue, there are some other attributes that could possibly be added to the entity. @andrewsayre any chance you could expand on those here? 😄
Related issue (if applicable): fixes #20889
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#8493
Example entry for configuration.yaml (if applicable):

Checklist:

[X] The code change is tested and works locally.
[X] Local tests pass with tox. Your PR cannot be merged unless tests pass
[X] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[X] New dependencies have been added to the REQUIREMENTS variable (example).
[X] New dependencies are only imported inside functions that use them (example).
[X] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.

If the code does not interact with devices:

[X] Tests have been added to verify that the new code works.

This looks really good -- but there's a few things to address.  I'll add my review this evening and we get this get this to done!!  Please don't merge until then.

@andrewsayre - Thanks for the review and the awesome work with library/integration, it's so easy to work with! Will make those changes you have mentioned, great idea grabbing the attributes such as the CodeId, that's going to be useful for notifications etc.

Added docs home-assistant/home-assistant.io/pull/8493

The tests are going to start failing until #21025 is merged.

The tests are going to start failing until #21025 is merged.

It's merged and I restarted the build.

👍 Approved.  Can be merged once build passes.

I think we're good here!

Cool! Time to stop mqtt and smartthings bridge to save power.

Thanks @andrewsayre!! 😄


Multi-project setup with scala.js performs unnecessary work

In a multi-project setting, even when there is no change to a subproject (or its dependent projects), fastOptJS performs some work for any change in other parts of the project. Here is a repo that can be used to reproduce the issue: https://github.com/ramnivas/scalajs-multi-project-issue. The essential part is that subproject1 depends on subproject2 and root aggregate them all.
$ sbt
...
> ~fastOptJS
...
[success] Total time: 4 s, completed Feb 28, 2015 4:55:55 PM
1. Waiting for source changes... (press enter to interrupt)

=== Now make some trivial change to ScalaJSExample in subproject1 ===

[info] Compiling 1 Scala source to /Users/ramnivas/template-dev/scalajs-multi-project-issue/subproject1/target/scala-2.11/classes...
[info] Fast optimizing /Users/ramnivas/template-dev/scalajs-multi-project-issue/target/scala-2.11/root-fastopt.js
[info] Fast optimizing /Users/ramnivas/template-dev/scalajs-multi-project-issue/subproject2/target/scala-2.11/subproject2-fastopt.js
[info] Fast optimizing /Users/ramnivas/template-dev/scalajs-multi-project-issue/subproject1/target/scala-2.11/subproject1-fastopt.js
[success] Total time: 3 s, completed Feb 28, 2015 4:56:23 PM

While I expected subproject1 and root to perform some work, the [info] Fast optimizing /Users/ramnivas/template-dev/scalajs-multi-project-issue/subproject2/target/scala-2.11/subproject2-fastopt.js part seems unnecessary.
p.s. This is the continuation of exploration mentioned in #1513

Also fixed by #1505 and #1507.

I am guessing this doesn't need a recompile for it to be used in dependent projects, correct?
e.g. if uTest depends on 0.6.0 and your project depends on 0.6.1 and uTest, this fix is "included" right?

My understanding is that my project needs to not only use scalajs 0.6.1, but also a uTest version that is compiled with 0.6.1.

@ramnivas is right. Just depending on Scala.js 0.6.1 will remove a lot of the unnecessary work (because the standard library upgrades) but some parts of uTest will be reoptimized every time something changes in the project or is dependencies.
Independently, with 0.6.1, if nothing changed in a project and any of its dependencies, then fastOpt will avoid doing any work whatsoever. But this is another issue #1491, which doesn't need recompilation to be applied.


Changing the default profile full name does not change full name in /settings.

If changing the full name in /settings this is also reflected in /profiles/id though.
I guess the expected behaviour would be that it also works vice versa...

Thanks


MCS pose generation for FEC

Description
This PR is a first pass at reworking the current FEC pose generation workflow to be more modular to make it easy to substitute parts or the entire workflow.
The idea is to break up the current workflow into a series of component parts rather than monolithic functions which do everything.
Assuming a prepared receptor and a set of ligands I think this boils down to:

[X] state enumeration (tautomers, protonation, stereo) #414
[x] constrained pose generation against some reference ligand in the given receptor
[x] filtering based on receptor clashes
Other PRs
relaxation (MM or ML/MM FEGrow style)
scoring (docking, ML or some combination)
return best conformation per molecule

Todos
Notable points that this PR has either accomplished or will accomplish.

[ ] TODO 1

Questions

[ ] Question1

Status

[ ] Ready to go

Once this PR is picked back up, here's a suggested change for the MCS code. This will allow us to do restrained docking while having wildcards on atoms, which is useful for e.g. when we want to restrain a ring in space while substituting out atom types between ligands. The current MCS code doesn't recognize *, using an OEQMolBase does:
if core_smarts:
    smarts_mol = oechem.OEGraphMol()
    oechem.OESmilesToMol(smarts_mol, core_smarts)
    pattern_query = oechem.OEQMol(smarts_mol)
    atomexpr = oechem.OEExprOpts_DefaultAtoms
    bondexpr = oechem.OEExprOpts_DefaultBonds
    pattern_query.BuildExpressions(atomexpr, bondexpr)
    ss = oechem.OESubSearch(pattern_query)

    oechem.OEPrepareSearch(refmol, ss)
    for match in ss.Match(refmol):
        core_fragment = oechem.OEGraphMol()
        oechem.OESubsetMol(core_fragment, match)
        logging.debug(f'Truncated refmol to generate core_fragment: {oechem.OEMolToSmiles(core_fragment)}')
        break

does the rich console also print ETA for all these stages?

does the rich console also print ETA for all these stages?

Currently not we could make it but its made slightly awkward when using Epik as that runs all the ligands in one go so it won't give a sensible estimate, but we could for each of the other stages. Note that it takes around 30s to run 32 molecules excluding the Epik stage locally.

Currently not we could make it but its made slightly awkward when using Epik as that runs all the ligands in one go so it won't give a sensible estimate, but we could for each of the other stages. Note that it takes around 30s to run 32 molecules excluding the Epik stage locally.

ok, let's keep in mind for a future PR if this turns out to be useful.

@hmacdope , @JenkeScheen I think this is finally done and ready for another pass.


Add actual effective genesis date

And re-generate ten year issuance chart using date

GenesisDate in this refers to the date the first time blocks are being produced, i.e. the start of Epoch 2?

Correct! Thanks for reviewing


Resource watch re-subscription uses wrong resource version and floods the k8s API server

Setup

Rancher version: 0e2fdc8
Browser type & version:

Describe the bug

The Vue dashboard uses websockets to subscribe to kubernetes events in the downstream cluster. The watch has a default timeout of 30 minutes. If the dashboard is left open for more than that, the watch will expire and the dashboard will attempt to resubscribe. However, the watch request requires a resource version to start the watch from, and the dashboard is providing an invalid version, causing the subscription to fail. The page must be refreshed in order to properly re-start the watch. In extreme cases with a large scale, this causes the kubernetes API server to become overloaded.
To Reproduce

Create a downstream cluster. Turn on debug logging for the agent by setting CATTLE_DEBUG to true in the environment variable configuration for the cluster. Turn on verbose logging for the kubernetes API server by editing the YAML, and under rancher_kubernetes_engine_config->services->kube-api add a section
...
kube-api:
  extra_args:
    v: '3'
...

When the cluster is running, navigate to "Deployments" under "Workloads". Create at least one workload, like a Deployment or Statefulset, or deploy an App and come back to the workloads tab. Open the Network tab.
EDIT reproducing this depends on having the List resource version be extremely skewed from the resource version of the item that is picked as a base. To reproduce this consistently, create AND delete several (i.e. tens to hundreds) of Deployments. THEN navigate to the Workloads tab and refresh. If the watch is started while Deployments are being created and deleted, the resource version used may come from one of the websocket updates, and the problem will not be visible, but if there is no activity happening, it will be picked from the last list response.
Result
In the Network tab, you can see the initial requests for the list of objects relevant to Workloads, for example:
GET https://<server>/k8s/clusters/<cluster>/v1/apps.statefulsets

:arrow_right:
{
    "type": "collection",
    "links": {
        "self": "..."
    },
    "createTypes": {
        "apps.statefulset": "..."
    },
    "actions": {},
    "resourceType": "apps.statefulset",
    "revision": "400478",
    "data": [
        {
            "id": "cattle-prometheus/prometheus-cluster-monitoring",
            "type": "apps.statefulset",
            "links": {
               ...
            },
            "apiVersion": "apps/v1",
            "kind": "StatefulSet",
            "metadata": {
                "name": "prometheus-cluster-monitoring",
                "namespace": "cattle-prometheus",
                 ...
                "resourceVersion": "17159",
            ....
        }
        {
            .... another statefulset ....
        }

In one of the websocket requests (for me it's always wss://<server>/k8s/clusters/<cluster>/v1/subscribe?sockId=3), you can see an outgoing websocket message to start a watch for that resource type and version:
:arrow_up_small: {"resourceType":"apps.statefulset","resourceVersion":"400478"}
After 30 minutes, the watch is closed (which is expected, because of the default timeout):
:arrow_down_small: {name: "resource.stop", resourceType: "apps.statefulset", data: {type: "subscribe", links: {}}}
We then see a new outgoing watch request, but now for a completely different resource version:
:arrow_up_small: {"resourceType":"apps.statefulset","resourceVersion":"17159"}
The watch immediately fails and is closed:
:arrow_down_small: {name: "resource.stop", resourceType: "apps.statefulset", data: {type: "subscribe", links: {}}}
and the cycle continues.
In the cluster agent debug logs, you can see the watch being stopped and started on repeat:
time="2022-05-19T23:16:34Z" level=debug msg="opening watcher for batch.job"
time="2022-05-19T23:16:34Z" level=debug msg="opening watcher for apps.statefulset"
time="2022-05-19T23:16:34Z" level=debug msg="opening watcher for namespace"
time="2022-05-19T23:16:34Z" level=debug msg="closing watcher for namespace"
time="2022-05-19T23:16:34Z" level=debug msg="closing watcher for batch.job"
time="2022-05-19T23:16:34Z" level=debug msg="closing watcher for apps.statefulset"
time="2022-05-19T23:16:36Z" level=debug msg="Wrote ping"
time="2022-05-19T23:16:36Z" level=debug msg="Wrote ping"
time="2022-05-19T23:16:37Z" level=debug msg="Wrote ping"
time="2022-05-19T23:16:37Z" level=debug msg="Wrote ping"
time="2022-05-19T23:16:40Z" level=debug msg="opening watcher for apps.statefulset"
time="2022-05-19T23:16:40Z" level=debug msg="opening watcher for batch.job"
time="2022-05-19T23:16:40Z" level=debug msg="closing watcher for batch.job"
time="2022-05-19T23:16:40Z" level=debug msg="closing watcher for apps.statefulset"
time="2022-05-19T23:16:40Z" level=debug msg="opening watcher for namespace"

On the kubernetes API server, you will see it being hammered by repeat GET requests with the URL including watch=true.
It turns out this resourceVersion is from one individual item in the list of resources, see JSON above. This is not the revision number returned for the collection by steve. Steve fails to initialize the watch because the resource version is "too old".
Note that kubernetes uses the field resourceVersion both for the version of the List and the versions of the individual resources, where steve changes the List's resourceVersion to revision.
When re-subscribing after a timeout, the revision number for the whole collection needs to be used, not the resource version number of any one item in the collection.
Expected Result

After a timeout, a new watch is started successfully and is ongoing until the next timeout.
Screenshots

Additional context

This may not be 100% reproducible because sometimes the item resource version is close enough to the collection revision that the watch still works, but this is an accident. If you deploy additional workloads and apps without making updates to any of them, eventually the collection revision number will get significantly bigger while the original item version number stays the same, and you should see the issue occur.

To help with debugging, I've proposed a change to steve which will

return a resource.error event through the websocket if the connection is closed irregularly
logs the error in the cluster agent
allows you to decrease the timeout from 30 minutes, by setting CATTLE_WATCH_TIMEOUT_SECONDS to, e.g. 300 (5 minutes) in the cluster agent environment.

The agent image with this change is published as cmurpheus/rancher-agent:v2.6-head-0e2fdc-steve-debug. EDIT: new image with latest changes at cmurpheus/rancher-agent:v2.6-head-f4e1de7-steve-debug

Connects to internal reference SURE-3208 amongst others potentially (SURE-4484)

Whoever takes this on, @cmurphy is happy to help.

As noted in the linked PR (https://github.com/rancher/dashboard/pull/6024), we have a fix for this via Harvester but this needs to be reviewed first.

@rak-phillip to look this over and sync with @cmurphy to see if the existing PR helps out here or if other work is required. Then we'd need to test.

Can we also get an estimate on when this would have started happening. Has it existed since the beginning of dashboard, or was it introduced at some point in time ?

I spoke with @cmurphy offline and I think we should merge rancher/steve#49 because it looks like it fixes the issue that we're experiencing today. We can still make some changes to Dashboard to improve on the behavior described above, but the change to Steve should resolve this issue:

Update our caching mechanism to to distinguish between list and item resources. I'm not seeing a way to improve on this with what's immediately available to us in dashboard. We make use of the type (e.g. catalog.cattle.io.app) and attempt to look up the latestresourceVersion by making use of Math.max()..
I think we would be able to make use of resyncWatch if Steve was able to relay to Dashboard that the revision is too old in the resource.stop event. Dashboard currently doesn't have any information available to discern if the cache is invalidated unless we receive a message that contains too old in the resource.error event.. I think we'd be able to appropriately make use of the local cache and resyncWatch if we could make use of something like 410 Gone on the resource.stop event. https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes

@gaktive

Was able to reproduced after creating/deleting around 30 deployments and waiting roughly 45 minutes.
Observed websockets with sockId1 and sockId3 starting and stopping various watches.
https://user-images.githubusercontent.com/85186645/173459786-12676e16-a4f6-46b3-98dc-d5ba428a5905.mp4
Observed cattle-agent debug logs confirming that watchers were being opened and closed repeatedly.

Observed very high rate of WATCH requests on jobs resources, matching the observed watcher starts/stops.

I tried to repro this recently and couldn't - I'm assuming that's because Colleen's PR was merged.
@rak-phillip I'm curious about this sentence in the doc you linked above:

For subscribing to collections, Kubernetes client libraries typically offer some form of standard tool for this list-then-watch logic. (In the Go client library, this is called a Reflector and is located in the k8s.io/client-go/tools/cache package.)

I wonder why we have an in-house implementation of findAll, or if there is a better tool that can be used with Vue.

Need to revisit in 2.7.0 with the backend team

Internal reference: SURE-5317
Question that floated up:

would tuning CATTLE_WATCH_TIMEOUT_SECONDS provide any relief?

That setting is for debugging only. The default is 30 minutes. It does not matter what you change the setting to, because the problem is not how often it occurs, it is that it occurs at all. To reiterate what I said in https://github.com/rancher/dashboard/issues/5997#issuecomment-1162478045

The flood of requests was corrected, but the dashboard is still doing incorrect behavior that can still be reproduced following the instructions above.

The flooding issue was worked around in steve, so users will mostly not notice the issue, so there is no "relief" needed. This issue is still open because the behavior is still incorrect.

This also appears to affect rancher/rancher#39033. It would be best to have this fixed before we attempt to handle the ghost cluster issue from the backend side any further.

Manually reopening as github bot has failed to do so

2.6.x backport: https://github.com/rancher/dashboard/issues/7779

Actual backport ticket: https://github.com/rancher/dashboard/issues/7707 (7779 closed as duplicate)

I have retested this issue and from my understanding of this issue and the merged PRs, this issue should be closed. I am not seeing repetitions of the same websocket IDs and it seems that the stop -> start watch behavior now uses sensible version #s.
Content of websocket messages before and after a stop:

Websocket IDs after multiple timeouts:

I'm running Rancher 2.6.11 and I'm not convinced that the backported fix in #7719 has actually resolved the problem.  We are still seeing surges of cattle-cluster-agent watch start/stop events:

These surges are correlated with high CPU and memory utilization on kube-apiserver as well as high latency in the Rancher UI and kubectl commands.

More data collected -- the correlation looks too close to ignore.  Here's the userAgent=agent/v0.0.0 API calls:

And here's the same timespan but looking at the resource watch start/stop events in the cattle-cluster-agent debug log:

@cmurphy  should I open a new issue about this, or can/should we reopen this one?  Or should we abandon 2.6.x and try to upgrade to 2.7.2+?

@skaven81 apologies for the delayed response. It would be a good idea to upgrade to 2.7.3 but I don't know if it would help with this issue. The main fix to the watch subscription spam issue was actually in https://github.com/rancher/steve/pull/49 which went into 2.6.7, so this should have already been addressed.
In your graphs, it looks like there are predictable surges which resolve themselves in a regular pattern. In this original issue, the re-subscription attempts were increasing at a constant rate after the initial timeout, so I would expect the graphs to continue on a straight path until the pod crashes and the line would fall off a cliff to zero. I think the surges you are seeing are probably normal and the performance issues you are seeing on those intervals could be alleviated by adding more memory and CPU. If you disagree, I would recommend opening a new issue because the symptoms you've described don't fully match the original issue.

In your graphs, it looks like there are predictable surges which resolve themselves in a regular pattern.

That's not "predictable surges" shown in the graph.  The entire width of that zigzag line is a single event.  Not a series of short ones.  The behavior we see is that a Rancher UI browser session will hit some sort of corner case condition (probably something similar to what was fixed in rancher/steve#49 with watch subscriptions timing out), and at that point, we see a huge spike of kube-apiserver calls from the cattle-cluster-agent using the agent/v0.0.0 userAgent string.  The kube-apiserver calls have the "acting as" metadata associated so we can see that the calls are being executed on behalf of the user whose browser has gone haywire.  Interestingly, there is no additonal traffic coming from the web browser -- the traffic is entirely (or mostly) between cattle-cluster-agent and kube-apiserver in the downstream cluster.  Not between the browser and rancher, and not between rancher and the cattle-cluster-agent.
The zig zags you see in the charts are zoomed into one of these events.  It shows how the cattle-cluster-agent begins logging a series of watch stop/start events, while simultaneously hammering the kube-apiserver in the same pattern.

In this original issue, the re-subscription attempts were increasing at a constant rate after the initial timeout, so I would expect the graphs to continue on a straight path until the pod crashes and the line would fall off a cliff to zero

Yeah that's definitely not what we see.  It has always been this sudden increase of kube-apiserver traffic for a single user (associated with one browser session) which then holds steady until the user closes their browser or refreshes the tab, at which point I guess the watches get re-established and kube-apiserver traffic for that user drops back to a normal level.
I'll open a new case for this.

Thanks!

@cmurphy  I have created https://github.com/rancher/rancher/issues/41663 to track the other related issue.


iOS VM services consistently takes 4 min to attach

Happens on both flutter attach and flutter run on an iOS 14 beta 7 device.
Xcode build done.                                           20.2s
Installing and launching...                                        35.5s
Waiting for iPhone to report its views...                            3ms
Syncing files to device iPhone...
238,259ms (!)

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
h Repeat this help message.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).
An Observatory debugger and profiler on iPhone is available at: http://localhost:53417

@jonahwilliams can you take a look while Jenn's out? 4 minutes seems somewhat specific. Might be something we're doing in the tool.

I don't have an iOS device

@xster do you have a verbose log?

I tried to reproduce this with iOS 14 beta 7 and xcode beta 5 and didn't have a problem.  @xster what version of xcode did you have?  I can try upgrading that as well.

[ +110 ms] executing: [/Users/xster/development/flutter/] git -c log.showSignature=false log -n 1 --pretty=format:%H
[  +37 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[        ] c81e8ceeba802f4765847a3e20f4f1064335c94a
[        ] executing: [/Users/xster/development/flutter/] git tag --points-at HEAD
[  +18 ms] Exit code 0 from: git tag --points-at HEAD
[   +1 ms] executing: [/Users/xster/development/flutter/] git describe --match *.*.* --first-parent --long --tags
[  +34 ms] Exit code 0 from: git describe --match *.*.* --first-parent --long --tags
[        ] 1.22.0-9.0.pre-79-gc81e8ceeba
[   +8 ms] executing: [/Users/xster/development/flutter/] git rev-parse --abbrev-ref --symbolic @{u}
[   +7 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/cupertino-icon-4
[        ] executing: [/Users/xster/development/flutter/] git ls-remote --get-url origin
[   +7 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] git@github.com:xster/flutter.git
[  +17 ms] executing: [/Users/xster/development/flutter/] git rev-parse --abbrev-ref HEAD
[   +7 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] cupertino-icon-4
[  +33 ms] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[   +1 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[   +4 ms] Artifact Instance of 'MaterialFonts' is not required, skipping update.
[        ] Artifact Instance of 'GradleWrapper' is not required, skipping update.
[        ] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidGenSnapshotArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[        ] Artifact Instance of 'FlutterSdk' is not required, skipping update.
[        ] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[  +29 ms] Artifact Instance of 'IosUsbArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FontSubsetArtifacts' is not required, skipping update.
[   +6 ms] executing: /usr/bin/xcode-select --print-path
[   +7 ms] Exit code 0 from: /usr/bin/xcode-select --print-path
[        ] /Applications/Xcode-beta.app/Contents/Developer
[   +1 ms] executing: /usr/bin/xcodebuild -version
[ +123 ms] Exit code 0 from: /usr/bin/xcodebuild -version
[        ] Xcode 12.0
           Build version 12A8189n
[  +43 ms] executing: /Users/xster/Library/Android/sdk/platform-tools/adb devices -l
[   +6 ms] executing: xcrun --find xcdevice
[  +11 ms] Exit code 0 from: xcrun --find xcdevice
[        ] /Applications/Xcode-beta.app/Contents/Developer/usr/bin/xcdevice
[        ] executing: xcrun xcdevice list --timeout 2
[   +3 ms] /usr/bin/xcrun simctl list --json devices
[        ] executing: /usr/bin/xcrun simctl list --json devices
[  +33 ms] List of devices attached
           8AXX11BS6              device usb:339812352X product:blueline model:Pixel_3 device:blueline transport_id:1
[ +111 ms] {
                      "devices" : {
                        "com.apple.CoreSimulator.SimRuntime.tvOS-14-0" : [cut because it was super long]...
[  +60 ms] Attempting to forward device port 57067 to host port 52782
[        ] executing: /Users/xster/development/flutter/bin/cache/artifacts/usbmuxd/iproxy 52782:57067 --udid cdcd493527f1f25a0ac91106540cf58186f2b4f0
[+1031 ms] Forwarded port ForwardedPort HOST:52782 to DEVICE:57067
[   +2 ms] Connecting to service protocol: http://<IP_ADDRESS>:52782/lp2aCOQkyas=/
[   +1 ms] DDS is currently disabled due to https://github.com/flutter/flutter/issues/62507
[  +97 ms] Successfully connected to service protocol: http://<IP_ADDRESS>:52782/lp2aCOQkyas=/
[   +3 ms] Waiting for iPhone to report its views...
[  +14 ms] Waiting for iPhone to report its views... (completed in 5ms)
[   +8 ms] DevFS: Creating new filesystem on the device (null)
[   +8 ms] DevFS: Creating failed. Destroying and trying again
[        ] DevFS: Deleting filesystem on the device (null)
[  +14 ms] DevFS: Deleted filesystem on the device (null)
[   +4 ms] DevFS: Created new filesystem on the device (file:///private/var/mobile/Containers/Data/Application/4E3829B9-194E-417C-B1A1-72DF26822582/tmp/ios_app_cliprdQp6S/ios_app_clip/)
[   +1 ms] Updating assets
[ +126 ms] Syncing files to device iPhone...
[   +1 ms] Scanning asset files
[   +3 ms] <- reset
[        ] Compiling dart to kernel with 0 updated files
[   +7 ms] /Users/xster/development/flutter/bin/cache/dart-sdk/bin/dart --disable-dart-dev /Users/xster/development/flutter/bin/cache/artifacts/engine/darwin-x64/frontend_server.dart.snapshot --sdk-root
/Users/xster/development/flutter/bin/cache/artifacts/engine/common/flutter_patched_sdk/ --incremental --target=flutter --debugger-module-names --experimental-emit-debug-metadata -Ddart.developer.causal_async_stacks=true
--output-dill /var/folders/p_/rttdvms52djbfmdb5__9xn980000gn/T/flutter_tools.ad7hVK/flutter_tool.KILLi1/app.dill --packages .packages -Ddart.vm.profile=false -Ddart.vm.product=false
--bytecode-options=source-positions,local-var-info,debugger-stops,instance-field-initializers,keep-unreachable-code,avoid-closure-call-instructions --enable-asserts --track-widget-creation --filesystem-scheme
org-dartlang-root --initialize-from-dill build/cache.dill.track.dill
[   +9 ms] <- compile package:ios_app_clip/main.dart
[+6165 ms] Updating files
[+236158 ms] Error writing "build/flutter_assets/fonts/MaterialIcons-Regular.otf" to DevFS: HttpException: , uri = http://<IP_ADDRESS>:52782/lp2aCOQkyas=/
[        ] trying again in a few - 9 more attempts left
[        ] Error writing "build/flutter_assets/FontManifest.json" to DevFS: HttpException: , uri = http://<IP_ADDRESS>:52782/lp2aCOQkyas=/
[        ] trying again in a few - 9 more attempts left
[ +557 ms] DevFS: Sync finished
[        ] Syncing files to device iPhone... (completed in 242,905ms, longer than expected)
[        ] Synced 1.7MB.
[   +1 ms] <- accept
[   +2 ms] Connected to _flutterView/0x10a837420.
[   +1 ms] Flutter run key commands.
[   +2 ms] r Hot reload. 🔥🔥🔥
[   +1 ms] R Hot restart.
[        ] h Repeat this help message.
[        ] d Detach (terminate "flutter run" but leave application running).
[        ] c Clear the screen
[        ] q Quit (terminate the application on the device).
[        ] An Observatory debugger and profiler on iPhone is available at: http://<IP_ADDRESS>:52782/lp2aCOQkyas=/

@xster are you sure your cable is working properly?

😅 shouldn't be the case. On some cases, it goes through fairly quickly. I haven't quite figured out what the pattern is yet.
A fast case
[+1009 ms] Forwarded port ForwardedPort HOST:53285 to DEVICE:52620
[ +326 ms] Installing and launching... (completed in 20.6s)
[   +2 ms] Caching compiled dill
[  +32 ms] Connecting to service protocol: http://localhost:53285
[   +1 ms] DDS is currently disabled due to https://github.com/flutter/flutter/issues/62507
[ +223 ms] Successfully connected to service protocol: http://localhost:53285
[   +1 ms] Waiting for iPhone to report its views...
[   +8 ms] Waiting for iPhone to report its views... (completed in 7ms)
[   +9 ms] DevFS: Creating new filesystem on the device (null)
[  +44 ms] DevFS: Created new filesystem on the device (file:///private/var/mobile/Containers/Data/Application/1A0741C6-8BC9-48E0-B644-1D7FCB8C477E/tmp/t172_new_cupertino_iconsKo60C8/t172_new_cupertino_icons/)
[   +1 ms] Updating assets
[  +79 ms] Syncing files to device iPhone...
[   +1 ms] Scanning asset files
[   +1 ms] <- reset
[        ] Compiling dart to kernel with 0 updated files
[   +1 ms] <- recompile package:t172_new_cupertino_icons/main.dart db1c7c70-5894-4504-b581-445cb0f09e25
[        ] <- db1c7c70-5894-4504-b581-445cb0f09e25
[  +34 ms] Updating files
[ +173 ms] DevFS: Sync finished
[        ] Syncing files to device iPhone... (completed in 213ms)
[        ] Synced 1.8MB.
[        ] <- accept
[   +3 ms] Connected to _flutterView/0x107832820.
[   +1 ms] Flutter run key commands.
[   +1 ms] r Hot reload. 🔥🔥🔥
[        ] R Hot restart.
[        ] h Repeat this help message.
[        ] d Detach (terminate "flutter run" but leave application running).
[        ] c Clear the screen
[        ] q Quit (terminate the application on the device).
[        ] An Observatory debugger and profiler on iPhone is available at: http://localhost:53285

Though 10 tries on this seems pretty possibly the problem:
Error writing "build/flutter_assets/fonts/MaterialIcons-Regular.otf" to DevFS: HttpException: , uri = http://<IP_ADDRESS>:52782/lp2aCOQkyas=/
[        ] trying again in a few - 9 more attempts left
[        ] Error writing "build/flutter_assets/FontManifest.json" to DevFS: HttpException: , uri = http://<IP_ADDRESS>:52782/lp2aCOQkyas=/

[        ] trying again in a few - 9 more attempts left

if it eventually passes it sounds like the connection is flaky.

Removing p2 for now since it doesn't happen all the time. I meant that it consistently has trouble on the same spot for some projects and never has trouble in some other projects.
I'll try another cable in a bit.

@xster I was able to verify no problem with Xcode beta 6 and iOS preview 7.

Had a report in Dart-Code that seems like the same issue. Here's the verbose output:
[   +2 ms] Updating assets
[ +209 ms] Manifest contained wildcard assets. Inserting missing file into build graph to force rerun. for more information see #56466.
[  +14 ms] Scanning asset files
[   +3 ms] <- reset
[        ] Compiling dart to kernel with 0 updated files
[   +1 ms] <- recompile package:TEST/main.dart a10c0db5-edba-4310-9a5a-1a343c2a9ef9
[        ] <- a10c0db5-edba-4310-9a5a-1a343c2a9ef9
[ +130 ms] Updating files
[+238747 ms] Error writing "build/flutter_assets/packages/font_awesome_flutter/lib/fonts/fa-solid-900.ttf" to DevFS: HttpException: , uri = http://localhost:54165
[        ] trying again in a few - 9 more attempts left
[ +532 ms] DevFS: Sync finished
[   +1 ms] Synced 2.1MB.
[   +1 ms] <- accept
[   +3 ms] Connected to _flutterView/0x10a839420. Connecting to VM Service at ws://localhost:54165/ws

[+238747 ms] is also almost exactly 4 minutes.

FWIW, https://github.com/flutter/gallery is the repo I can reliably reproduce this on.

I also encountered this problem. I tried to replace the USB data cable, and the same thing happened after replacing the data cable

I've had the same issue. When it happens I try running in verbose to capture more logs, but then it always works fine. When I disable verbose mode, it breaks again. It seems to happen randomly and I can't nail it down. Happens on two of my computers running the same flutter/vscode version combo.

I got lucky and was able to catch it with a verbose log. It seems like there's a 4 minute timeout and copying an asset fails the first time, but it takes 4 minutes to timeout:
[2:56:45 PM]: <== [ +109 ms] Process 9936 detached
[2:56:45 PM]: <== [  +63 ms] Application launched on the device. Waiting for observatory port.
[2:56:45 PM]: <== [   +8 ms] Attempting to forward device port 56605 to host port 59141
[2:56:45 PM]: <== [        ] executing: /Users/andrewcoutts/Projects/flutter/bin/cache/artifacts/usbmuxd/iproxy 59141:56605 --udid 00008030-0016283036BB802E
[2:56:46 PM]: <== [+1007 ms] Forwarded port ForwardedPort HOST:59141 to DEVICE:56605
[2:56:46 PM]: <== [   +9 ms] HttpException: Connection closed before full header was received, uri = http://localhost:59141/ws
[2:56:48 PM]: <== [{"event":"app.progress","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","id":"1","progressId":null,"finished":true}}]
[2:56:48 PM]: <== [+2151 ms] Caching compiled dill
[2:56:48 PM]: <== [  +58 ms] Connecting to service protocol: http://localhost:59141
[2:56:48 PM]: <== [        ] DDS is currently disabled due to https://github.com/flutter/flutter/issues/62507
[2:56:48 PM]: <== [  +21 ms] Successfully connected to service protocol: http://localhost:59141
[2:56:48 PM]: <== [{"event":"app.progress","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","id":"2","progressId":null,"message":"Waiting for xff0c-se to report its views..."}}]
[2:56:48 PM]: <== [{"event":"app.progress","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","id":"2","progressId":null,"finished":true}}]
[2:56:48 PM]: <== [   +7 ms] DevFS: Creating new filesystem on the device (null)
[2:56:48 PM]: <== [  +11 ms] DevFS: Created new filesystem on the device (file:///private/var/mobile/Containers/Data/Application/FDD3DE51-12F7-44D1-B049-AC0DC178EA98/tmp/appOCXTPc/app/)
[2:56:48 PM]: <== [   +1 ms] Updating assets
[2:56:48 PM]: <== [{"event":"app.debugPort","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","port":59141,"wsUri":"ws://localhost:59141/ws","baseUri":"file:///private/var/mobile/Containers/Data/Application/FDD3DE51-12F7-44D1-B049-AC0DC178EA98/tmp/appOCXTPc/app/"}}]
[2:56:49 PM]: <== [ +426 ms] Manifest contained wildcard assets. Inserting missing file into build graph to force rerun. for more information see #56466.
[2:56:49 PM]: <== [{"event":"app.progress","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","id":"3","progressId":null,"message":"Syncing files to device xff0c-se..."}}]
[2:56:49 PM]: <== [   +9 ms] Scanning asset files
[2:56:49 PM]: <== [   +5 ms] <- reset
[2:56:49 PM]: <== [        ] Compiling dart to kernel with 0 updated files
[2:56:49 PM]: <== [   +1 ms] <- recompile package:bottlepay/main.dart 7e82e1fb-bf5a-4e51-8f25-0c71cc32dfbf
[2:56:49 PM]: <== [        ] <- 7e82e1fb-bf5a-4e51-8f25-0c71cc32dfbf
[2:56:49 PM]: <== [  +70 ms] Updating files
[3:00:47 PM]:
<== [+237701 ms] Error writing "build/flutter_assets/assets/flare/screen2.flr" to DevFS: HttpException: , uri = http://localhost:59141
[3:00:47 PM]: <== [        ] trying again in a few - 9 more attempts left
[3:00:47 PM]: <== [ +529 ms] DevFS: Sync finished
[3:00:47 PM]: <== [{"event":"app.progress","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","id":"3","progressId":null,"finished":true}}]
[3:00:47 PM]: <== [        ] Synced 7.9MB.
[3:00:47 PM]: <== [        ] <- accept
[3:00:47 PM]: <== [   +2 ms] Connected to _flutterView/0x10c050a20.
[3:00:47 PM]: <== [{"event":"app.started","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf"}}]
[3:00:48 PM]: ==> [{"id":"1","method":"app.callServiceExtension","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","methodName":"ext.flutter.platformOverride"}}]
[3:00:48 PM]: ==> [{"id":"2","method":"app.callServiceExtension","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","methodName":"ext.flutter.inspector.structuredErrors","params":{"enabled":true}}}]
[3:00:48 PM]: ==> [{"id":"3","method":"app.callServiceExtension","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","methodName":"ext.flutter.brightnessOverride"}}]
[3:00:48 PM]: ==> [{"id":"4","method":"app.callServiceExtension","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","methodName":"ext.flutter.inspector.setPubRootDirectories","params":{"arg0":"/Users/andrewcoutts/Projects/app","arg1":"/Users/andrewcoutts/Projects/app","isolateId":"isolates/3558716148370031"}}}]
[3:00:48 PM]: ==> [{"id":"5","method":"app.callServiceExtension","params":{"appId":"8e58214b-f44d-4adb-a7d4-7cb7db340acf","methodName":"ext.flutter.inspector.isWidgetCreationTracked"}}]
[3:00:48 PM]: <== [{"id":"1","result":{"value":"iOS","type":"_extensionType","method":"ext.flutter.platformOverride"}}]
[3:00:48 PM]: <== [{"id":"2","result":{"enabled":"true","type":"_extensionType","method":"ext.flutter.inspector.structuredErrors"}}]
[3:00:48 PM]: <== [{"id":"3","result":{"value":"Brightness.dark","type":"_extensionType","method":"ext.flutter.brightnessOverride"}}]
[3:00:48 PM]: <== [ +546 ms] flutter: ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[3:00:48 PM]: <== [   +2 ms] flutter: │ #0   main (package:bottlepay/main.dart:216:23)

I suppose I produced some variant of this. flutter create an app on master and run against iOS 14. If you tap the local network dialog after some reasonable delay (say 5s), it seems like it might have exhausted an exponential backoff and the next train is at 4 min.

FYI a lot of users report the same error message in in https://github.com/flutter/flutter/issues/63800

I'm bumping the priority on this one a bit since it'll affect all users creating new projects on iOS then running on iOS 14 physical devices AFAICT. @jmagman could you take a look? Is suspect our polling is a bit spread out to catch a small delay in the user clicking through the network dialog.

I tried reproducing this again with the gallery app.  I wasn't able to:
Launching lib/main.dart on Aaron’s iPhone in debug mode...
Found saved certificate choice "Apple Development: Aaron Clarke (XXXXXXXX)". To clear, use "flutter config".
Signing iOS app for device deployment using developer identity: "Apple Development: Aaron Clarke (XXXXXXXX)"
Running Xcode build...
 └─Compiling, linking and signing...                         8.1s
Xcode build done.                                           15.6s
Installing and launching...                                        33.3s
Waiting for Aaron’s iPhone to report its views...                    5ms
Syncing files to device Aaron’s iPhone...
 3,297ms (!)

I wonder if there was a problem with a server that the tools were communicating with?  Something like Apple's server for checking certificates?  Can someone that can reproduce the problem try to reproduce the problem while not connected to the internet?

Same problem as https://github.com/flutter/flutter/issues/63800.
Same problem as https://github.com/flutter/flutter/issues/63869.
Has nothing to do with iOS 14 or Xcode 12.
It's a pretty bad problem that has been going on for awhile now. Surprised it hasn't received more traction.

@gaaclarke were you telling me this morning that it's not the network dialog? Please change the title again if I still have it wrong.


ica-context-switcher inside shell script doesn't elevate to admin privileges

bash L2100746__L2100745__dragen_somatic_with_germline_pipline_3_9_3_test.launch.sh
Validating workflow inputs against ICA workflow version definition (if ica-ica-lazy is installed)
--ica-workflow-id and --ica-workflow-version-name are defined, getting inputs from definition
Checking name attribute is present
Name value is good
Checking input is present
Ensuring that all required inputs are present:  output_directory_germline output_directory_somatic output_file_prefix_germline output_file_prefix_somatic reference_tar
Input 'fastq_list_rows.0.read_1.location' is a gds file at 'gds://development/primary_data/210708_A00130_0166_AH7KTJDSX2/202203122acad425/WGS_TsqNano/MDX210175_L2100745_S5_L001_R1_001.fastq.gz' checking it's present.
Input 'fastq_list_rows.0.read_2.location' is a gds file at 'gds://development/primary_data/210708_A00130_0166_AH7KTJDSX2/202203122acad425/WGS_TsqNano/MDX210175_L2100745_S5_L001_R2_001.fastq.gz' checking it's present.
Input 'reference_tar.location' is a gds file at 'gds://development/reference-data/dragen_hash_tables/v8/hg38/altaware-cnv-anchored/hg38-v8-altaware-cnv-anchored.tar.gz' checking it's present.
Input 'tumor_fastq_list_rows.0.read_1.location' is a gds file at 'gds://development/primary_data/210708_A00130_0166_AH7KTJDSX2/202203122acad425/WGS_TsqNano/MDX210176_L2100746_S6_L001_R1_001.fastq.gz' checking it's present.
Input 'tumor_fastq_list_rows.0.read_2.location' is a gds file at 'gds://development/primary_data/210708_A00130_0166_AH7KTJDSX2/202203122acad425/WGS_TsqNano/MDX210176_L2100746_S6_L001_R2_001.fastq.gz' checking it's present.
Input is good
Checking engineParameters
engineParameters is good
code    Workflows.Workflow.PermissionOnResourceRequired
message The wes.runs.create permission is required on the resource to complete this operation.

Closing, cannot be reproduced


Replace HTTPotion by HTTPoison

This commit replaces the deprecated HTTPotion by the hackney-based HTTPoison.
Beyond the fact that we're no longer dependent on a deprecated lib, this also enables connection pooling, which can make sequential requests to the Bot Framework API faster.
Since this is a major change, I've also included a bit of a refactor to the Client modules.
For the changelog
Replaced ExMicrosoftBot.Client.headers/2 by ExMicrosoftBot.Client.authed_headers/1, which removes the need for fetching the auth token to build valid request headers.
Replaced ExMicrosoftBot.Client.req_opts/0 by ExMicrosoftBot.Client.opts/1.
Removed the http_timeout config and introduced the http_client_opts config. There doesn't seem to be an analog in HTTPoison for this as it looks like it was used by :ibrowse as a default value for connection and
request timeouts. Should be replaced by http_client_opts: [timeout: X] and http_client_opts: [recv_timeout: X] respectively.
Adds ExMicrosoftBot.Client.get/2, ExMicrosoftBot.Client.delete/2, ExMicrosoftBot.Client.put/3, and ExMicrosoftBot.Client.post/3.

@zabirauf done! Thanks for the review.

@jmnsf FYI, published the new package to Hex. Thanks for the change
https://hex.pm/packages/ex_microsoftbot/3.0.0


mqtt timeout

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
Monitoring a topic in mqtt broker, payload is 'up' or 'down'.  When topic does not match, heartbeat show all red [down][timeout}. Then when the topic matches, one heartbeat shows green [up], followed by red [down][timeout].
Expected behavior is when the topic matches, each 60sec the heartbeat should be green [up]
📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1.23.11
💻 Operating System and Arch
debian 12 in proxmox VE
🌐 Browser
chrome
🐋 Docker Version
No response
🟩 NodeJS Version
No response

Closing as Duplicate of #3855
Note that our contribution guide can be found here: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md


Add instructions for connecting to VNC server using Mac OS X

Before I merge this, I want to check and see if a TCP proxy could be configured using labels on the Selenium container allowing vnc://selenium.exampleproject.test to be used on both linux and macOS without needing to have Reminas tunnel via SSH or require the SSH tunnel be created on macOS. This thought is what has held me back on merging #116 as well, which wouldn't work on macOS since Reminas does not exist (to my knowledge) for macOS at this time.

In order to use the hostnames, each instance would need its own proxy (since afaik VNC doesn't have any concept of SNI)
I tried to get some sort of TCP routing working through Traefik but so far have been entirely unsuccessful at getting Traefik to identify my TCP router labels or even acknowledge them in its logs.

I would think, in the interim, updating the docs for the current usage is still a good idea ;)

True…I won't let it hold this up, but the PR introducing a Linux only cmd to Warden will need to wait till I can look into that. Good notes. Thanks!


No longer can transit from native Activity to Hotwire Activity using navigator.route

After I migrated from turbo-native to hotwire-native, I no longer have the native activity transitioning to hotwire activity.
Perhaps is just a simple issue and I must admit that I'm definitely not an expert in Android development, so I'd really appreciate some help.
Below is the code for the function. I debugged it until the navigator.route(signInUrl) .
There are no exceptions in the Tomcat's log.
Attached is a video that I recorded. Notice that all that happens after I touch the Continue with Google, is the action bar blinking.
   private fun handleSignInResult(completedTask: Task<GoogleSignInAccount>) {
        try {
            val account = completedTask.getResult(ApiException::class.java)
            // Signed in successfully, show authenticated UI.
            CookieManager.getInstance().setCookie(BASE_URL, "id_token=${account.idToken}") {
                val signInUrl = "${BASE_URL}/turbo_native/sessions/create"
                navigator.route(signInUrl)
            }
        } catch (e: ApiException) {
            showAlert("Sign-in failed", "Error: ${e.statusCode}")
        }
    }

https://github.com/user-attachments/assets/1d8e51e0-0698-4a88-8b39-7fcb194d7f56

Hey @diegocharles this is intentional and a change in Hotwire Native. You'll note that there is no longer an API available to register Activity destinations like you can register Fragment destinations. Android (and Google) have been moving away from multi-Activity structured apps, and rather than provide an inconsistent experience in Hotwire Native for Activities, those must now be manually handled by the app with an Intent. Using multiple Activities in an app should be an exception, not the rule.
Corresponding PR: https://github.com/hotwired/hotwire-native-android/pull/10
To launch a new Activity, call:
val intent = Intent(context, AnotherActivity::class.java)
context.startActivity(intent)

Hi @jayohms
I genuinely appreciate your support. Thank you!
I apologize for the confusion; I meant to say “Fragment” instead of “Activity.” 🤦♂
I have implemented a GoogleSignInFragment as an Android native screen. I want to navigate to the “session/create” route, but for some reason, the “navigator.route(url)” function isn’t working since I migrated from Turbo Native to Hotwire Native.
In fact, it doesn’t navigate to any URL, not just “sessions/create.”
Do you have any advice on how to resolve this issue?

@diegocharles I'd take a look at the demo app's (in this repo) DemoApplication class and make sure you're registering fragments correctly. You'll also want to make sure that the DemoApplication class is registered as your main Application class in your manifest file.
Other than that:

Make sure your path configuration uris match your destination uris
Ensure that your urls match
Ensure that you're using the default route decision handlers or have custom ones setup correctly

@jayohms I appreciate your help. Thank you buddy!


Long loading part of site (pot with items)

Hello !
I have a another problem .
I install everything like in tutorial work perfectly but ...
Part of site  -  container with pot info ( items in pot , placed items ) stuck on loading... over 20-30 secound.
Any one have issue like that ? I will be greatfull for any suggest :)
Thanks !
Additional info :
It is on  VPS with core 2 duo / 2 GB or Ram / and 100MB/s network
Lastest PHP and MSQL

What on the earth is this?
#427 I suppose.

You are probably looking for https://github.com/ztizzlegaming/CSGOWinBig
Post there instead.


Improve CSS specificity determination

See this comment: https://github.com/LearnBoost/juice/commit/90330700
Basically this adds support for the :not() pseudo and for comma separated selectors.
My version converted everything to numbers instead of arrays (which is easier to compare), so I had to adjust it a bit.
I didn't ran your tests, don't looked how to get all the tests running, but it should work. More tests can be found here: https://github.com/arian/DOM/blob/matcher-specificity/Specs/spec/specificity.js

Btw comma separated is not necessary because I analyze selectors one by one.

oh, updated...

Thanks Arian! 0.0.2


Error with eslint no-unresolved since 6.2.0

See the error here: https://travis-ci.org/mozilla/addons-frontend/jobs/252183587#L1977
Since 6.2.0 I get the following error when running eslint against my repo (addons-frontend): Unable to resolve path to module 'react-onclickoutside'  import/no-unresolved
This happens for 6.3.x as well. Not sure what caused it but it isn't happening elsewhere, wondering if there was a recent refactor/change of file structure that would've caused it.

that's very odd, as 6.3 should have been a rollback to 6.1... let me try to re-rollback O_o

@Andarist any idea?

I've published 6.4, which should be a reversion to 6.1.1 - let me know if that's fixed things @tofumatt

Passed all my tests. Thanks!

@Pomax @tofumatt
That is turbo strange o.O @tofumatt would u be able to provide a repository with reproduced issue? Would be helpful for debugging purposes.

Indeed, the repo is addons-frontend. Here are the relevant failing PRs:

https://github.com/mozilla/addons-frontend/pull/2731 (6.2.0, possibly unrelated)
https://github.com/mozilla/addons-frontend/pull/2732 (6.3.0)
https://github.com/mozilla/addons-frontend/pull/2733 (6.3.1)

Thanks, gonna set it up in a minute !

Ok, I know what happened. es directory was not published on those versions, and the resolver (rightfully) tried to access it (as specified in package.json's module entry).
@Pomax prepublish script should be added to ensure valid publications

@Andarist whatever was the latest node 7.x with npm 3.x - I updated it since due to the Nodejs security advisory since, so maybe npm3 was too low and it needed 4 or 5?

Hm, aint sure how to properly maintain scripts for various version of npm. there might not be any, but as only u have publishing rights and u have updated ur node and npm (from what I understand) - this shouldnt happen anymore.
Anyway - republishing what got reverted should be made I think.

We should probably add an engines section to the package.json like { "engines" : { "npm" : ">=4" } }

@Andarist want to file a new PR with the changes on top of 6.4? I can then publish it with node 8/npm5 which should work.

@Pomax , yeah, thought about adding engines, although they are just mere warnings (unless strict option is provided) and they also warn on installation of the package by the consumers, where we dont really want do that - we'd like to warn/error only during development of the package

@Pomax wanted to send PR as requested, but im quite not sure how did u revert the changes and how the process went, dont want to mess up with history etc
I.e. this https://github.com/Pomax/react-onclickoutside/pull/201 was merged in according to github, but its not visible in the history, have u tampered with git's history by resetting it or smth? Same with this - https://github.com/Pomax/react-onclickoutside/pull/202

I rolled back to the 6.1.1 release, and then forced that as master, then spun a new version directly from that. So the history between 6.1.1 and 6.4 has been removed from the master branch on github.

I see you like living on the edge 😄 I'll send PRs with what got reseted in a minute


Limiting tests: reducing the time of the news recommendation GPU notebooks

Description

Reducing the test time of the limiting tests. I reduced the epochs and increased the batch size
Related Issues

related to https://github.com/microsoft/recommenders/issues/995#issuecomment-1055722538
Checklist:

[x] I have followed the contribution guidelines and code style for this project.
[ ] I have added tests covering my contributions.
[ ] I have updated the documentation accordingly.
[x] This PR is being made to staging branch and not to main branch.

@pradnyeshjoshi, in a VM could you please run:
git pull
git checkout limiting_tests
pytest tests/integration/examples/test_notebooks_gpu.py::test_nrms_quickstart_integration --durations
pytest tests/integration/examples/test_notebooks_gpu.py::test_naml_quickstart_integration --durations
pytest tests/integration/examples/test_notebooks_gpu.py::test_lstur_quickstart_integration --durations
pytest tests/integration/examples/test_notebooks_gpu.py::test_lstur_quickstart_integration --durations

There are two errors that might be expected:

OOM because the batch size is too high
errors in the metrics

@pradnyeshjoshi, in a VM could you please run:
git pull
git checkout limiting_tests
pytest tests/integration/examples/test_notebooks_gpu.py::test_nrms_quickstart_integration --durations
pytest tests/integration/examples/test_notebooks_gpu.py::test_naml_quickstart_integration --durations
pytest tests/integration/examples/test_notebooks_gpu.py::test_lstur_quickstart_integration --durations
pytest tests/integration/examples/test_notebooks_gpu.py::test_lstur_quickstart_integration --durations

There are two errors that might be expected:

OOM because the batch size is too high
errors in the metrics

pytest tests/integration/examples/test_notebooks_gpu.py::test_nrms_quickstart_integration --durations=10
==================================================================== test session starts =====================================================================
platform linux -- Python 3.7.12, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
rootdir: /home/pradjoshi/recommenders, configfile: tox.ini
plugins: hypothesis-6.31.5, cov-3.0.0
collected 1 item

tests/integration/examples/test_notebooks_gpu.py .                                                                                [100%]/home/pradjoshi/anaconda3/envs/reco-env/lib/python3.7/site-packages/coverage/report.py:87: CoverageWarning: Couldn't parse '/home/pradjoshi/recommenders/recommenders/evaluation/tf_evaluation.py': No source for code: '/home/pradjoshi/recommenders/recommenders/evaluation/tf_evaluation.py'. (couldnt-parse)
  coverage._warn(msg, slug="couldnt-parse")

====================================================================== warnings summary ======================================================================
../anaconda3/envs/reco-env/lib/python3.7/site-packages/ansiwrap/core.py:6
  /home/pradjoshi/anaconda3/envs/reco-env/lib/python3.7/site-packages/ansiwrap/core.py:6: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
    import imp

../anaconda3/envs/reco-env/lib/python3.7/site-packages/papermill/iorw.py:50
  /home/pradjoshi/anaconda3/envs/reco-env/lib/python3.7/site-packages/papermill/iorw.py:50: FutureWarning: pyarrow.HadoopFileSystem is deprecated as of 2.0.0, please use pyarrow.fs.HadoopFileSystem instead.
    from pyarrow import HadoopFileSystem

tests/integration/examples/test_notebooks_gpu.py: 4219 warnings
  /home/pradjoshi/anaconda3/envs/reco-env/lib/python3.7/site-packages/jsonschema/validators.py:197: DeprecationWarning: Passing a schema to Validator.iter_errors is deprecated and will be removed in a future release. Call validator.evolve(schema=new_schema).iter_errors(...) instead.
    DeprecationWarning,

tests/integration/examples/test_notebooks_gpu.py::test_nrms_quickstart_integration[5-64-42-demo-expected_values0]
  /home/pradjoshi/anaconda3/envs/reco-env/lib/python3.7/site-packages/traitlets/config/configurable.py:85: DeprecationWarning: Passing unrecognized arguments to super(PapermillNotebookClient).__init__(input_path='/home/pradjoshi/recommenders/examples/00_quick_start/nrms_MIND.ipynb').
  object.__init__() takes exactly one argument (the instance to initialize)
  This is deprecated in traitlets 4.2.This error will be raised in a future release of traitlets.
    super(Configurable, self).__init__(**kwargs)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
------------------------------------------ generated xml file: /home/pradjoshi/recommenders/junit/test-results.xml -------------------------------------------

---------- coverage: platform linux, python 3.7.12-final-0 -----------
Name                                                                     Stmts   Miss  Cover
--------------------------------------------------------------------------------------------
recommenders/datasets/amazon_reviews.py                                    359    339     6%
recommenders/datasets/cosmos_cli.py                                         31     31     0%
recommenders/datasets/covid_utils.py                                        40      4    90%
recommenders/datasets/criteo.py                                             53     23    57%
recommenders/datasets/download_utils.py                                     50      5    90%
recommenders/datasets/mind.py                                              214    214     0%
recommenders/datasets/movielens.py                                         226     93    59%
recommenders/datasets/pandas_df_utils.py                                   137     18    87%
recommenders/datasets/python_splitters.py                                   57      5    91%
recommenders/datasets/spark_splitters.py                                    49     49     0%
recommenders/datasets/sparse.py                                             63      6    90%
recommenders/datasets/split_utils.py                                        49     12    76%
recommenders/datasets/wikidata.py                                           75     40    47%
recommenders/evaluation/python_evaluation.py                               269     17    94%
recommenders/evaluation/spark_evaluation.py                                224    224     0%
recommenders/models/deeprec/DataModel/ImplicitCF.py                         88     75    15%
recommenders/models/deeprec/deeprec_utils.py                               180     97    46%
recommenders/models/deeprec/io/dkn_item2item_iterator.py                    57     57     0%
recommenders/models/deeprec/io/dkn_iterator.py                             153    153     0%
recommenders/models/deeprec/io/iterator.py                                 105     91    13%
recommenders/models/deeprec/io/nextitnet_iterator.py                       119    119     0%
recommenders/models/deeprec/io/sequential_iterator.py                      223    223     0%
recommenders/models/deeprec/models/base_model.py                           312    312     0%
recommenders/models/deeprec/models/dkn.py                                  175    175     0%
recommenders/models/deeprec/models/dkn_item2item.py                         48     48     0%
recommenders/models/deeprec/models/graphrec/lightgcn.py                    170    170     0%
recommenders/models/deeprec/models/sequential/asvd.py                       16     16     0%
recommenders/models/deeprec/models/sequential/caser.py                      42     42     0%
recommenders/models/deeprec/models/sequential/gru4rec.py                    28     28     0%
recommenders/models/deeprec/models/sequential/nextitnet.py                  61     61     0%
recommenders/models/deeprec/models/sequential/rnn_cell_implement.py        282    282     0%
recommenders/models/deeprec/models/sequential/sequential_base_model.py     149    149     0%
recommenders/models/deeprec/models/sequential/sli_rec.py                    49     49     0%
recommenders/models/deeprec/models/sequential/sum.py                        57     57     0%
recommenders/models/deeprec/models/sequential/sum_cells.py                 143    143     0%
recommenders/models/deeprec/models/xDeepFM.py                              208    208     0%
recommenders/models/fastai/fastai_utils.py                                  31     31     0%
recommenders/models/geoimc/geoimc_algorithm.py                              69     64     7%
recommenders/models/geoimc/geoimc_data.py                                   92     56    39%
recommenders/models/geoimc/geoimc_predict.py                                40     24    40%
recommenders/models/geoimc/geoimc_utils.py                                  13      8    38%
recommenders/models/lightfm/lightfm_utils.py                                72     27    62%
recommenders/models/ncf/dataset.py                                         249    168    33%
recommenders/models/ncf/ncf_singlenode.py                                  131    128     2%
recommenders/models/newsrec/io/mind_all_iterator.py                        262    261     1%
recommenders/models/newsrec/io/mind_iterator.py                            185     15    92%
recommenders/models/newsrec/models/base_model.py                           166     44    73%
recommenders/models/newsrec/models/layers.py                               118     69    42%
recommenders/models/newsrec/models/lstur.py                                 70     70     0%
recommenders/models/newsrec/models/naml.py                                 119    119     0%
recommenders/models/newsrec/models/npa.py                                   68     68     0%
recommenders/models/newsrec/newsrec_utils.py                                73     21    71%
recommenders/models/rbm/rbm.py                                             183    116    37%
recommenders/models/rlrmc/RLRMCalgorithm.py                                127    124     2%
recommenders/models/rlrmc/RLRMCdataset.py                                   57     49    14%
recommenders/models/rlrmc/conjugate_gradient_ms.py                         118    118     0%
recommenders/models/sar/sar_singlenode.py                                  159     60    62%
recommenders/models/sasrec/model.py                                        331    331     0%
recommenders/models/sasrec/sampler.py                                       48     48     0%
recommenders/models/sasrec/ssept.py                                         85     85     0%
recommenders/models/sasrec/util.py                                          71     71     0%
recommenders/models/surprise/surprise_utils.py                              29     29     0%
recommenders/models/tfidf/tfidf_utils.py                                   145     34    77%
recommenders/models/vae/multinomial_vae.py                                 179    179     0%
recommenders/models/vae/standard_vae.py                                    175    175     0%
recommenders/models/vowpal_wabbit/vw.py                                     67      3    96%
recommenders/models/wide_deep/wide_deep_utils.py                            31     31     0%
recommenders/tuning/nni/ncf_training.py                                     95     95     0%
recommenders/tuning/nni/ncf_utils.py                                        27      4    85%
recommenders/tuning/nni/nni_utils.py                                        71     11    85%
recommenders/tuning/nni/svd_training.py                                    101    101     0%
recommenders/utils/general_utils.py                                         13      4    69%
recommenders/utils/gpu_utils.py                                             69     56    19%
recommenders/utils/notebook_memory_management.py                            50     50     0%
recommenders/utils/notebook_utils.py                                        16      4    75%
recommenders/utils/plot.py                                                  34      1    97%
recommenders/utils/python_utils.py                                          40      2    95%
recommenders/utils/spark_utils.py                                           26     18    31%
recommenders/utils/tf_utils.py                                             128    125     2%
--------------------------------------------------------------------------------------------
TOTAL                                                                     9095   6732    26%

38 files skipped due to complete coverage.
Coverage XML written to file coverage.xml

==================================================================== slowest 10 durations ====================================================================
1841.90s call     tests/integration/examples/test_notebooks_gpu.py::test_nrms_quickstart_integration[5-64-42-demo-expected_values0]

(2 durations < 0.005s hidden.  Use -vv to show these durations.)
======================================================= 1 passed, 4222 warnings in 1845.26s (0:30:45) ========================================================

@pradnyeshjoshi do you think we can merge this PR?

@anargyri @laserprec there is a weird error in the coverage, any idea of what could be the problem?

The error is relating to merging all the code coverage reports from the various runs before sending to codecov. When merging, coverage is trying to look for the local install path of the package to finalize the coverage numbers, but such path does not exist outside of the test machine, thus the error: No source for code: '/home/azureuser/localfiles/runner/work/recommenders/recommenders/recommenders/__init__.py'.
As it turns out, codecov can merge the reports for us, I think we can skip the merging step and send all of the .coverage* files to codecov instead.


docs: detail improvement for running nydus

Fix the section about nerdctl usage;
Improve some details for whole doc;

Signed-off-by: Yan Song<EMAIL_ADDRESS>

@imeoer , a new test job has been submitted. Please wait in patience.

@imeoer , The CI test is completed, please check result:

Test CaseTest Result

merge-target-branch:white_check_mark:SUCCESS

build-docker-image:white_check_mark:SUCCESS

compile-nydus:white_check_mark:SUCCESS

compile-ctr-remote:white_check_mark:SUCCESS

compile-nydus-snapshotter:white_check_mark:SUCCESS

start-nydus-snapshotter-config-containerd:white_check_mark:SUCCESS

run-container-with-nydus-image:white_check_mark:SUCCESS

Congratulations, your test job passed!


Invalid URI, if array in query params

I have a problem with an array in query params.
Example:
$url = 'https://example.localhost/?fields[articles]=title';
$uri = new Uri($url, UriParser::MODE_UTF8);

Error:
InvalidArgumentException
/Kit-UrlParser/src/Uri.php:54

I have no influence on the generation of the Urls, because they come from another extension.
Have you got a solution for this problem?

Strictly speaking, the problem is that [ and ] are not valid characters in the query part of the URI according to rfc3986 and this library was originally created with the intention of validating URLs strictly according to that RFC.
The extension you are using really ought to build URLs using logic similar to http_build_query(), so that the [] characters would get encoded properly like fields%5Barticles%5D=title.
But, I do realize that unfortunately a lot of places do not really conform to the spec very strictly so I might have to think about adding some kind of lenient parsing mode that would allow more characters than what the spec defines.


[AutoRelease] t2-rdbms-2023-09-26-25748(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/4567
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=1020

issue link:https://github.com/Azure/sdk-release-request/issues/4567


Reconnecting fails with ConnectionResetError

I'm connecting to clickhouse using the asynch Pool. If I let the connection idle for a few minutes, apparently the server closes the connection on its end. Now, the next time I try to execute a query using an existing pool, asynch gets a ConnectionResetError during ping(), this is still handled gracefully, however when reconnecting, asynch tries to close the already closed connection and crashes, again with a ConnectionResetError. (On a sidenote: Sometimes I get a BrokenPipeError instead of ConnectionResetError)
I managed to fix this quick-and-dirty by wrapping self.writer.close() in a try-except. Another option could be to set connection.connected = False in the error handling inside ping().
Demo code:
import logging

from asynch import Pool
import asyncio

logging.basicConfig()
logging.getLogger("asynch.proto.connection").setLevel(logging.DEBUG)

connection_string ='clickhouse://@p4c0wmo0db.germanywestcentral.azure.clickhouse.cloud:9440/production?secure=True'

loop = asyncio.new_event_loop()

async def init_pool():
    pool = Pool(minsize=1, maxsize=2, dsn=connection_string)
    await pool.startup()
    return pool

async def execute(pool):
    async with pool.connection() as conn:
        async with conn.cursor() as cursor:
            await cursor.execute("SELECT 1")
            ret = await cursor.fetchone()
            assert ret == (1,)

pool = loop.run_until_complete(init_pool())
loop.run_until_complete(execute(pool))
# wait five minutes
loop.run_until_complete(execute(pool))

And output:
DEBUG:asynch.proto.connection:Connecting. Database: production. User: production_tacto_api_user
DEBUG:asynch.proto.connection:Connecting to p4c0wmo0db.germanywestcentral.azure.clickhouse.cloud:9440
DEBUG:asynch.proto.connection:Connected to ClickHouse server version 24.6.1, revision: 54468
DEBUG:asynch.proto.connection:Query: SELECT 1
# wait five minutes
DEBUG:asynch.proto.connection:Socket closed
Traceback (most recent call last):
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/connection.py", line 309, in ping
    packet_type = await self.reader.read_varint()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/streams/buffered.py", line 139, in read_varint
    if not (await self._is_buffer_readable()):
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/streams/buffered.py", line 117, in _is_buffer_readable
    await self._refill_buffer()
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/streams/buffered.py", line 111, in _refill_buffer
    await self._read_into_buffer()
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/streams/buffered.py", line 127, in _read_into_buffer
    packet = await self.reader.read(self.buffer_max_size)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/nilsborrmann/.pyenv/versions/3.12.7/lib/python3.12/asyncio/streams.py", line 713, in read
    await self._wait_for_data('read')
  File "/Users/nilsborrmann/.pyenv/versions/3.12.7/lib/python3.12/asyncio/streams.py", line 545, in _wait_for_data
    await self._waiter
  File "/Users/nilsborrmann/.pyenv/versions/3.12.7/lib/python3.12/asyncio/selector_events.py", line 988, in _read_ready__get_buffer
    nbytes = self._sock.recv_into(buf)
             ^^^^^^^^^^^^^^^^^^^^^^^^^
ConnectionResetError: [Errno 54] Connection reset by peer
WARNING:asynch.proto.connection:Connection was closed, reconnecting.
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/Users/nilsborrmann/.pyenv/versions/3.12.7/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "<input>", line 23, in execute
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/cursors.py", line 88, in execute
    response = await execute(query, args=args, with_column_types=True, **execute_kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/connection.py", line 630, in execute
    and types.
 ^^^^^^^^^^^^^^
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/context.py", line 53, in __aenter__
    await self._connection.disconnect()
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/connection.py", line 565, in disconnect
    try:
    ^^^^^
  File "/Users/nilsborrmann/PycharmProjects/pythonProject/.venv/lib/python3.12/site-packages/asynch/proto/streams/buffered.py", line 64, in close
    await self.writer.wait_closed()
  File "/Users/nilsborrmann/.pyenv/versions/3.12.7/lib/python3.12/asyncio/streams.py", line 364, in wait_closed
    await self._protocol._get_close_waiter(self)
ConnectionResetError: [Errno 54] Connection reset by peer

% pip freeze
asynch==0.2.5
ciso8601==2.3.1
leb128==1.0.8
lz4==4.3.3
pytz==2024.2
tzlocal==5.2
zstd==<IP_ADDRESS>

@nils-borrmann-tacto , hello.
This example does not reproduce the problem you encountered, locally two runs went fine.
Example:
import asyncio
import logging
from time import sleep

from asynch import Pool

logging.basicConfig(
    level=logging.DEBUG, format="Example %(asctime)s %(message)s", datefmt="%Y-%m-%d %H:%M:%S"
)

# connection_string ='clickhouse://@p4c0wmo0db.germanywestcentral.azure.clickhouse.cloud:9440/production?secure=True'

async def init_pool() -> Pool:
    pool = Pool(minsize=1, maxsize=2)  # , dsn=connection_string)
    await pool.startup()
    return pool

async def execute(pool: Pool):
    async with pool.connection() as conn:
        async with conn.cursor() as cursor:
            await cursor.execute("SELECT 1")
            ret = await cursor.fetchone()
            assert ret == (1,)

async def main():
    pool = await init_pool()
    await execute(pool)
    sleep(5 * 60)  # waiting for 5 minutes
    await execute(pool)
    await pool.shutdown()

if __name__ == "__main__":
    asyncio.run(main())

Result:

Hi @stankudrow thanks for the quick reply.
In your run, it didn't print this line

WARNING:asynch.proto.connection:Connection was closed, reconnecting.

So it didn't run into the crash, because the server didn't close the connection. It was able to re-use the existing connection just fine. The crash only happens when a previously opened connection cannot be reused because it was closed by the server.
I am using clickhouse cloud, and this is likely a behaviour that is not replicated by a local install. I will see if I can better reproduce the issue locally, maybe by killing the locally running clickhouse instance.

Hi @stankudrow thanks for the quick reply.
In your run, it didn't print this line

WARNING:asynch.proto.connection:Connection was closed, reconnecting.

So it didn't run into the crash, because the server didn't close the connection. It was able to re-use the existing connection just fine. The crash only happens when a previously opened connection cannot be reused because it was closed by the server.
I am using clickhouse cloud, and this is likely a behaviour that is not replicated by a local installation of clickhouse. I will see if I can better reproduce the issue locally, maybe by killing the locally running clickhouse instance.

Yep, such an example would be nice to have as a unit test, but I am not sure I can compose one today.


feat: add PDM_MULTIRUN_CURRENT environment variable

This PR adds a small change to make the name of the current interpreter or virtual environment available under the environment variable PDM_MULTIRUN_CURRENT. This is particularly useful for cases when the name of a virtual environment may not be equal to the specific python version.

Altered accordingly, added a bit more to the docs on that feature and the example to make it clearer.
Side point - wasn't sure what the preferred line length is for markdown here, I assumed 80?

CI issue should be fixed by #6


feat: add update-stripe-card route

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

Definitely, This page is not linked anywhere. It will be used once we add this route to the payment provider's settings.
We should be able to test this page even on production before it gets used.


Pin versions of packages (e.g. numpy==1.0.0) so no issues with breaking changes

Fixed - will be pushed later today.


Sending to group

I added secrets, added the action, posted an issue and get this error.
Is posting to groups not supported?

Ty works

@ManuelSchneid3r You use the old tag. Please see the action page: https://github.com/marketplace/actions/telegram-message-notify the latest tag is v0.1.1

I see thank you. I spent some hours to find out but no success so far. how can I send links to the github pull requests and issues?


Add utility function to unregister the IUTF background monitoring task

This allows a test case to revoke a registration of a background task to continue later with a reentry function.

Added documentation

related to #466

LGTM. Tests are failing due to the docker-igorpro images being out-of-date. The MacOSX tests pass so I'll merge anyway.