Where is wiki of repositories?

If you want this to be fixed, you should report it to the original app https://github.com/jonan/ForkHub. This app is just a copy.
This issue is probably the same as https://github.com/jonan/ForkHub/issues/127


Enable CloudSQL UWS database for TAP (Initially just for the idfdev SSOTAP service)

PR Summary:
This PR addresses Jira issue DM-44524: Move the UWS database for SSO-TAP to CloudSQL
A summary of the changes introduced to enable the feature:
Changes to cadc-tap chart:

Add optional cloudsql configuration to values
Add optional UWS database / username configuration to values
Optional serviceaccount.yaml / Used when cloudsql is enabled
Make uws optional (add enabled: true | false).
Make UWS (uws database that get's deployed as part of cadc-tap until now) resources optional, only deployed when uws enabled
Add cloudsql proxy container option to tap-deployment / Deployed if cloudsql is enabled
Add Helm unit tests that use: https://github.com/helm-unittest/helm-unittest/

Changes to applications/ssotap:

Set serviceAccount in values to default to "ssotap"
Enable cloudsql / Disable uws for idfdev. Set parameters so that CloudSQL is used for UWS (using Proxy) / Use tap-postgres image 1.16.0 (which includes auto-initialisation)
Add secrets-idfdev.yaml (new secret for UWS CloudSQL database for idfdev)

Changes to github CI workflow:

Enable Helm unittest to be run

Other relevant changes:

A Postgres database has been created in GCP CloudSQL, named "ssotap" for idfdev
A secret to store the password for this database has been stored in OnePass

How was this tested:

Helm chart unit tests for cadc-tap
Tested sync & async queries to ssotap with the following scenarios:

Empty cloudsql ssotap UWS database
Non-empty cloudsql ssotap UWS database
cloudsql disabled / uws enabled

Detailed Description
Detailed description of steps taken, design decisions, as well as some question and potential issues found can be found here:
https://github.com/stvoutsin/rub-notes/wiki/DM‐44427-‐-Enable-CloudSQL-UWS-database-for-SSO-TAP-service
Other info:
The changes should be backwards compatible, i.e. no changes should be required to any of the other tap or ssotap applications. If there are I've missed something and should correct.

So first thing, that's a fantastic PR summary and stop making me look as lazy as I actually am, please.

I like the helm unit-testing sorcery.

One other thing: is there https://github.com/lsst/idf_deploy work that has to go along with the ssotap SA to get WI functioning?

The idf_deploy changes were already done in https://github.com/lsst/idf_deploy/pull/523.

One other thing: is there https://github.com/lsst/idf_deploy work that has to go along with the ssotap SA to get WI functioning? EDIT the linked notes say not, which feels weird to me. I mean, clearly the service is functioning, but I don't understand why there isn't a need for WI bindings over in the idf_deploy stuff.

I think I need to correct the links, as I may have missread that part of the documentation. I did create a SA in using Terraform, which I assume is all that is needed, as that get's passed in and used in the templates to connect via the proxy.


Disable private tenant for read only users

Signed-off-by: David Bennett<EMAIL_ADDRESS>opensearch-project/security-dashboards-plugin pull request intake form

Category: (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)

Bug fix

Github Issue # or road-map entry, if available:

https://github.com/opensearch-project/security-dashboards-plugin/issues/812

Description of changes:

If a user has a role that is configured as "read only" in opensearch_dashboards.yml, or if a user has the default read only role "kibana_read_only", make Dashboards behave as if the private tenant is disabled. You cannot choose "Private" in the tenant switch panel anymore, and a descriptive text is displayed in the tenant switch panel.

Why these changes are required?

If a user has a read only role, offering the possibility to use the private tenant does not make much sense. The read only role implies that only read operations are allowed. Since no one other as the current user is able to access the private tenant, but due to read only the current user is also not allowed to make any changes, selecting the private tenant in this situation is useless.

What is the old behavior before changes and new behavior after changes? (Please add any example/logs/screen-shot if available)

If a user has a read only role, the tenant switch panel would still allow to choose the private tenant.

Testing done: (Please provide details of testing done: Unit testing, integration testing and manual testing)

Added additional tests to password-reset-panel.test.tsx. Manual testing for different combinations of roles and read only  roles.

TO-DOs, if any: (Please describe pending items and provide Github issues# for each of them)

None.

Is it backport from main branch? (If yes, please add backport PR # and commits #)

No.
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #844 (cc4cb61) into main (c71a46c) will increase coverage by 0.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #844      +/-   ##
==========================================
+ Coverage   71.98%   72.10%   +0.11%
==========================================
  Files          87       87
  Lines        1906     1914       +8
  Branches      242      249       +7
==========================================
+ Hits         1372     1380       +8
  Misses        480      480
  Partials       54       54

Impacted Files
Coverage Δ

...rds-plugin/public/apps/configuration/constants.tsx
85.71% <0.00%> (ø)

...plugin/public/apps/account/tenant-switch-panel.tsx
91.11% <0.00%> (+0.86%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c71a46c...cc4cb61. Read the comment docs.

Tested on local cluster and the fix is working
However, we can only merge this after following tasks are done:

Rebase fixes to new main branch
Sign all commits with GPG signature, ref: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification

Please review Dave's comment on this PR https://github.com/opensearch-project/security-dashboards-plugin/pull/867

Closing in favor of #868


The width of search toolbar is too small and cannot be adjusted

Applies To

[X] Notebooks (.ipynb files)
[ ] Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?
When editing normal files, the width of search toolbar is large, and it can be adjusted by dragging the light gray vertical bar on the left side.

When working with Jupyter notebooks, the width of search toolbar is too small and cannot be adjusted. The search content is hardly to be seen.

VS Code Version
1.69.1
Jupyter Extension Version
v2022.6.1201981810
Jupyter logs
No response
Coding Language and Runtime Version
No response
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
No response
Running Jupyter locally or remotely?
Local

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


No 'Upload Conflict' dialog pops up when uploading an exist large blob

Storage Explorer Version: 1.2.0
Platform: Windows 10
Architecture: ia32
Build Number: 20180619.1
Commit: 3b2233d5
Regression From: This issue doesn't reproduce on released Storage Explorer 20180605.1.
Steps to Reproduce:

Launch Storage Explorer. Go to (subscription) > Storage Accounts.
Choose one blob container which contains a large blob at least. Upload an existing large blob.
Check whether the 'Upload Conflict' dialog pops up or not.

Expected Experience:
The 'Upload Conflict' dialog pops up.

Actual Experience:
No 'Upload Conflict' dialog pops up and fails to upload the existing large blob with the below error .

Hi @v-haiz ,
Does this only happen on "large" blobs? And in terms of "large", could you please give us some size threshold so we can reproduce this bug?

Yes, JasonYeMSFT, this only happen on large blobs, you can reproduce this bug through using about 30GB. Yesterday, I use the blob size of 30GB and use blobs more than 30GB also reproduce this bug.

@v-haiz Can you share with us what you find when clicking Details...? The error information there can help us pinpoint the problem.

Below is the picture when clicking Details...

Bug reported as fixed. Closing.

JasonYeMSFT fixed it. Should be in 1.3.0.

Awesome.
@v-haiz When sharing errors like this, you can just click the Copy Details and Report Issue to GitHub button to copy the text to your clipboard. Then you can paste it right here. No screenshots necessary!

@craxal OK, thanks for your friendly reminder.


feat: profiles search

Thank you for your contribution to the Koda - Generative Art Marketplace.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Feature

Needs Design check

@exezbcz please review

Needs QA check

@kodadot/qa-guild please review

Context

[x] Closes #10448
[x] Requires deployment https://github.com/kodadot/private-workers/pull/197

Did your issue had any of the "$" label on it?

[x] My DOT address: Payout

Screenshot 📸

[x] My fix has changed something on UI; a screenshot is best to understand changes for others.

@hassnian All have been updated

I would deploy it https://github.com/kodadot/private-workers/pull/197

@kodadot/internal-dev can you please deploy the profile worker ?

@kodadot/internal-dev can you please deploy the profile worker ?

I have deployed it


Add Github Annotation Output

We can use GitHub's workflow command to make annotations.
This is a POC that appends such commands.
Annotation will be display on GitHub like this:
https://github.com/binotaliu/x-ray-annotation-demo/commit/c280f8b717313eb78cf8e0b6bfc63db770d0d103#diff-0524b271e915e8060f768ae50abd7ea860fa5ec3b9d842218c2c207347d77f1d

Cool idea!


Posting an edge document using REST

OrientDB Version:  2.2.35
Java Version: 1.8.0_181
OS: 16.04
Expected behavior
I want to create a REST query similar to Vertex creation  to create an Edge
Actual behavior
No documentation to specify invertex and outvertex
Steps to reproduce
No documentation on how to create a POST call for an edge using REST
I do not want Raw queries because raw queries are hard to maintain in a big code base.

Hi @cegprakash
Currently there is no such API to create edges, I'm afraid you will have to fall back to SQL
Thanks
Luigi

Can you reopen this as a feature request?

Hi @cegprakash
Sure, but it will hardly be implemented in v 2.2.x.
There is a chance that it will be in v 3.1, but I cannot guarantee it
Thanks
Luigi


Issue "Can not find attachable Ruby process." with VSCode (on MacOS Sonoma)

Hi,
I am using VSCode 1.85.1 on macOS Sonoma and wanna debug a rails project. I run gem install debug and a which rdbg tells me that rdbg (1.9.1) should be right version from my asdf installation of ruby and rails (in /Users/XXX/.asdf/shims/rdbg).
After starting VSCode I run bundle exec rdbg --open -n -c -- bundle exec rails s which tells me (in first line of Terminal output) that
DEBUGGER: Debugger can attach via UNIX domain socket (/var/folders/5d/3_3p6jn50yd6qf_0648v_93w0000gn/T/ruby-debug-sock-501/ruby-debug-XXX-52985)
which looks fine/normal to me. With the following .vscode/launch.json

{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "rdbg",
"name": "Debug current file with rdbg",
"request": "launch",
"script": "${file}",
"args": [],
"askParameters": true
},
{
"type": "rdbg",
"name": "Attach with rdbg",
"request": "attach"
}
]
}

I run into the problem that I am getting error message "Can not find attachable Ruby process." in VSCode (by pressing "attach with rdbg"). Any ideas what I am missing?
THX a lot!
mscdit

DEBUGGER: Debugger can attach via UNIX domain socket (/var/folders/5d/3_3p6jn50yd6qf_0648v_93w0000gn/T/ruby-debug-sock-501/ruby-debug-XXX-52985)

It seems older debug.gem (~ 1.8.x). Could you try bundle exec rdbg -v?

Thanks a lot! bundle exec rdbg -v shows 1.6.3 ... and rdbg -v 1.9.1 ... updating bundle did the trick. It is working now!

Great!


toString() returning GMT+0 and GMT-0 on different systems

As explained in https://github.com/moment/moment/issues/1018, toString() is intended to produce consistent results regardless of the user's environment.  However, it is currently defined as follows:
function toString () {
    return this.clone().locale('en').format('ddd MMM DD YYYY HH:mm:ss [GMT]ZZ');
}

This implementation results in subtly different outputs on different systems (+0 vs -0), presumably due to different definitions of the 'en' locale:
    -         ng-reflect-date="Mon Jul 22 2019 00:00:00 GMT-0"
    +         ng-reflect-date="Mon Jul 22 2019 00:00:00 GMT+0"

I was able to workaround the issue with a variant of what was suggested here, redefining the moment.toString as follows for the affected tests:
  moment.fn.toString = function toString() {
      return this.format('ddd MMM DD YYYY HH:mm:ss [GMT]');
    };

But it seems to me that a better fix would be for toString to not rely on the system locale definition for 'en', for the same reason it does not rely on the system timezone setting.

Can you provide some more context about what version and plugins you're using?
The ZZ formatting token should always produce a 4-digit string (e.g. 0000), so I suspect it's not the core moment library causing the strange offset output (+0 / -0 instead of +0000)

Thanks, I've figured it out: .toString() was correctly outputting -0400 and +0400 respectively but the string was truncated by angular's ng-reflect at an awkward point.  Became clear once I wrote tests using timezones that cross the date line.
Apologies for the bother and thanks for looking!


Add possibility to adjust token revocation behaviour

Issue and Steps to Reproduce
Currently, if revocationEndpoint is present in OIDC server configuration, requests are created to revoke both access and refresh token (code). This behaviour is problematic when using some IdPs, for example AWS Cognito - as their revoke endpoint accepts only refresh token and revokes all access tokens issued to it (see docs). Therefore, one of the revocation requests will always fail and produce unnecessary error on console, which cannot be silenced from outside.
Versions
6.16.7
Screenshots

Expected
There is option (for example in OidcConfiguration) to skip revocation of given token - could be array with token names or just boolean flags.
Actual
No such option, one request always fails when using some providers (for example AWS Cognito).

Hi @krzempekk , thank you very much for your issue.
It is a very nice and simple enhancemet to add.

Hi @krzempekk , this feature is already working. May we close the issue?

Hi @guillaume-chervet! Sorry for the delay, feel free to close it.

thank you @krzempekk


Try to prevent update of user-type Windows installation when running as admin (#148428)

This PR fixes #148428

/assign @joaomoreno
I haven't worked out how I can test this when building OSS. Any ideas?

Thanks for the PR @gjsjohnmurray! I've changed it slightly so we run the check a bit earlier. I'll just run an internal build and test this out.


ConnectionRefusedError: [Errno 111] Connection refused

Hi,
nice job!
I have followed the installation steps, but when trying to connect to the mt5linux server I get this error:
ConnectionRefusedError: [Errno 111] Connection refused
How can I check independently if the server is working properly?
Thanks

You mean the window where I run the command to server?
This is what is there:

Can you please reply? IS the above screen shot saying anything about the server, or the serves is not working?

Try set host and/or port on both sides (linux and windows). This python -m mt5linux --help can help.

Hi Lucas,
I am confused. Shall the server run both linux and windows?What do you mean on both sides?I just use the default host/port. I also tried to change them but there is no difference. Shall I use the linux or window jupyter/python to run the scripts?The installation instruction say to install m5linux on linux, so I assume the server runs under linux python, otherwise it would also be necessary to install m5linux under windows as well. Can you please clarify?
So far I have followed the installation instructions and I am running/installing the server in linux, and the notebook also in linux jupyter.
Metatrader is running correctly in wine.

Now I see your problem. The server shall run on Windows. This library makes it possible for the client (Linux) to execute commands on the server side (Windows) and return its outputs/errors.

Thanks! So mt5linux should be installed with wine as well? I also need to run mt5linux on linux as a client?
Two installations, but run the server on windows(start from command line) and the client on linux(from notebook for example)? May be the installation instructions could clarify it explicitly.
Anyway thanks, it is a nice project!

Exactly, @newuser202201. I'm enhancing the instructions.

Thanks. Now I get this error:
I tried to change the path according to this page https://discuss.ray.io/t/winapi-createprocess-executable-args-filenotfounderror-winerror-2/5943/9, but I still get te same error. Any idea how to fix it?
WINEPREFIX=/root/.local/share/wineprefixes/mt5/ wine python.exe -m mt5linux ~/.local/share/wineprefixes/mt5/drive_c/urs/root/AppData/Local/Programs/Python/Python38-32
0144:fixme:file:server_get_file_info Unsupported info class e
0144:fixme:file:server_get_file_info Unsupported info class e
Traceback (most recent call last):
File "C:\users\root\AppData\Local\Programs\Python\Python38-32\lib\runpy.py", line 194, in _run_module_as_main
return run_code(code, main_globals, None,
File "C:\users\root\AppData\Local\Programs\Python\Python38-32\lib\runpy.py", line 87, in run_code
exec(code, run_globals)
File "C:\users\root\AppData\Local\Programs\Python\Python38-32\lib\site-packages\mt5linux_main.py", line 176, in
main()
File "C:\users\root\AppData\Local\Programs\Python\Python38-32\lib\site-packages\mt5linux_main.py", line 161, in main
Popen(['mkdir','-p',server_dir]).wait()
File "C:\users\root\AppData\Local\Programs\Python\Python38-32\lib\subprocess.py", line 858, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\users\root\AppData\Local\Programs\Python\Python38-32\lib\subprocess.py", line 1311, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] File not found

No Idea :/
Try to reinstall your subprocess lib.

I had to change the main of mt5linux and pass shell=True to Popen to avoid the error above. There is also another problem with the creation of the path to the server which is using \ instead of /. I am starting the server manually from wine with python.exe /tmp/mt5linux/server.py --host localhost -p 18812 and it seems to work, but the automatically generated command is /tmp/mt5linux\server.py, giving rise to the error. Obrigado

Hmm.. Could you create a MR?

This is the problem
os.path.join(server_dir,server_code)
It runs in windows, but the default path server_dir is /tmp/mt5, using Unix notation, wile os.path is using windows, so you get  /tmp/mt5\server.py, which rises an error. I ma not sure how to fix it, may be doing it by hands, but it would not be platform independent. The server runs in windows, but is using linux path convention. I can do the MR for shell=true, but the other I am not sure what you want to get.

I created a branch but I do not have the option to MR
https://github.com/lucas-campagna/mt5linux/pull/11

The server works, but I get no data:
image
From the python notebook I get nothing:
print(mt5.terminal_info())
print(mt5.version())
None
(0, 0, '')

I did some tests from windows python as well, using directly metatrader 5, and it is not working. The mt5 version installed by the script https://www.mql5.com/en/articles/625?utm_source=www.metaquotes.net&utm_campaign=download.mt5.linux is 32 bit, shall I use 64, i.e. the one installing terminal64.exe? What are you using? I also installed python32

https://www.mql5.com/en/forum/10114/page8
The last 64 build is crashing, so it is necessary to install an old one and remove access from the updates to avoid automatic updates. By the way, why not to just use python from wine to instead of the server? It works..

The server works, but I get no data:

From the python notebook I get nothing:
print(mt5.terminal_info()) print(mt5.version()) None (0, 0, '')

The server initialized but as shown above, the output is null.
I can run from wine python metatrader5 and it works, so the problem is not in Metatrader. What could be the cause?
Is linux  jupyter faster than wine jupyter ? Otherwise I dont see the advantage to use mt5linux


x/build: add LUCI openbsd-ppc64 builder

Following the instructions at Dashboard builders:
hostname openbsd-ppc64-n2vi
CSR is attached after renaming since Github doesn't seem to allow attaching with the name openbsd-ppc64-n2vi.csr you asked for.

Thanks. Here's the resulting resulting certificate: openbsd-ppc64-n2vi-1697128325.cert.txt.
I've mailed CLs to define your new builder in LUCI and will comment once that's done.

Thank you; I confirm that using the cert I get a plausible looking luci_machine_tokend/token.json.

Glad to hear!
Step 3 is complete (CL 534976 is submitted), so you should be able to proceed with the next steps. Please feel free to comment here if you see something unexpected, or run into a problem that the documentation doesn't cover. Thanks.

I have not read the code yet to diagnose this; leaving assigned to me.

2023/10/13 18:29:39 Bootstrapping the swarming bot with certificate authentication
2023/10/13 18:29:39 retrieving the luci-machine-token from the token file
2023/10/13 18:29:39 Downloading the swarming bot
2023/10/13 18:29:39 Starting the swarming bot /home/swarming/.swarming/swarming_bot.zip
72354 2023-10-13 18:29:47.331 E: ts_mon monitoring is disabled because the endpoint provided is invalid or not supported:
72354 2023-10-13 18:29:48.890 E: Request to https://chromium-swarm.appspot.com/swarming/api/v1/bot/handshake failed with HTTP status code 403: 403 Client Error: Forbidden for url: https://chromium-swarm.appspot.com/swarming/api/v1/bot/handshake
72354 2023-10-13 18:29:48.891 E: Failed to contact for handshake, retrying in 0 sec...

I don't see anything in the code or logs here that help me diagnose. It just looks like the server didn't like the token.json that had been refreshed just a minute before.
Maybe someone there  can check server-side luci logs? I'll attempt to reassign to dmitshur.

Thanks for the update.
I recall there was a similar looking error in https://github.com/golang/go/issues/61666#issuecomment-1706534225. We'll take a look.

In case it helps...  I set both -token-file-path on the bootstrapswarm command line and also LUCI_MACHINE_TOKEN in the environment. The logs don't indicate any trouble reading the token.json file, though they're not very explicit.
I appreciate that there have been serious security flaws in the past from too-detailed error messages. But I'd venture that it is safe for luci to say more than "403".
I recognize I'm a guinea pig for the Go LUCI stuff, so happy to give you a login on t.n2vi.com if you would find it easier to debug directly or hop on a video call with screen sharing.
Finally, I recognize I'm a newcomer to Go Builders. So it could well be user error here.

Thanks for your patience as we work through this and smooth out the builder onboarding process.

I set both -token-file-path on the bootstrapswarm command line and also LUCI_MACHINE_TOKEN in the environment.

To confirm, are both of them set to the same value, which is the file path location of the token.json file? If you don't mind experimenting on your side, you can check if anything is different if you leave LUCI_MACHINE_TOKEN unset and instead rely on the default location for your OS (/var/lib/luci_machine_tokend/token.json I believe).
We'll keep looking into this on our side. Though next week we might be somewhat occupied by a team event, so please expect some delays. Thanks again.

Yes, both are set to the same value  /home/luci/luci_machine_tokend/token.json. (My OS doesn't have /var/lib and anyway not a fan of leaving cleartext credentials in obscure corners of the filesystem.)
This morning I've retried the same invocation of bootstrapswarm as before and don't get the 403 Client Error. So maybe there was just a transient issue.
Happy to set this effort on the shelf for a week or two; enjoy the team event!

CC @golang/release.

Over the last week I tried swarm a few more times with no problems, so whatever issue I saw before indeed seems transient. I never saw swarm do any actual work, presumably because some server-side table is still pointing to my machine as in the old-builder state rather than new-builder. Fine by me.
I'll have limited ability to work on it from November 8 - 20, but happy to work on it during the next few days if you're waiting on me.

The builder is currently in a "Quarantined—Had 6 consecutive BOT_DIED tasks" state. @n2vi Can you please restart the swarming bot on your side and see if that's enough to get it out of that state?
We've applied changes on our side (e.g., CL 546715) that should help avoid this repeating, but it's possible more work will be needed. Let's see what happens after you restart it next time. Thanks.

Restarted.
There is a message from swarming_bot urllib3 that they only support openssl but this is compiled with libressl. From the GitHub issue cited, I think this is merely a warning but if you're otherwise stuck I can investigate deeper.
Or if there is something else I can do to help, just ask.
FWIW, on my other openbsd-ppc64 machine, I've succeeded in compiling go1.22-devel from tip without change. Both machines are running what OpenBSD calls -current, i.e. compiled from source as of a few days ago.

Any news on this?
t.n2vi.net aka host-openbsd-ppc64-n2vi had been getting kernel panics from the gopher buildlet stream so, amidst power outages and other troubles, I brought software up to date in an effort to debug. Go 1.22 is running fine here.
Currently the buildlet fails to compile and while I work on that I thought I'd check in parallel on LUCI progress. If we can just cut over to the new system maybe I don't need to debug the old one?

Thanks for checking in.
I've looked into this and as things stand now, there is expected additional time after the public Go 1.22.0 release, before it's available for the CIPD package building pipeline to use. This delay might decrease in the future, and we might be able to work around it, but not yet.
We'll update this issue after the CIPD packages are ready. Thanks.

@dmitshur any update on this given the hard deadline for May 17th?

@n2vi Can you try again?

I'm traveling, but will try remotely soon.
Just to confirm: you'd like both the old builder and the new swarming running in parallel for now, correct?

Killed off the old processes running as swarm, rebuilt golang.org/x/build/cmd/bootstrapswarm@latest, and tried to restart but got an error message about flag -token-file-path provided but not defined.
In the morning I'll start digging into what has changed in the API since October.

As long as you still have LUCI_MACHINE_TOKEN set as needed in the environment, you should be able to drop the -token-file-path flag. It used to be required to set both to the same value, and the flag was removed in CL 548955 in favor of the env var.

Thanks. Restarted without error messages.

Is there any work remaining before we close this issue?

Looking at the build history at https://ci.chromium.org/ui/p/golang/builders/luci.golang.ci/gotip-openbsd-ppc64?limit=200, it seems it hasn't had a chance to run with the latest changes. @n2vi Can you try restarting it again? Thanks.

That link tells me "You don't have the permission to view the machine pool" so not sure I have the ability to test much.
The most recent output from bootstrapswarm was on May 4:
Downloading the swarming bot
status code 401
I don't see any change from git in bootstrapswarm.go since February. Which are the "latest changes" you're referring to?
When I restart bootstrapswarm, I see the usual startup messages. If there is some dashboard I can access or other instructions I should follow, please let me know.

Sorry, I was referring to the "Ended Builds" section of that page, which you should be able to see.
Thanks for restarting the bot. I see a new recent build b8748292982685499841, and it failed to run "cipd ensure".
Errors:
  failed to resolve<EMAIL_ADDRESS>(line 9): no such package: golang/bootstrap-go/openbsd-ppc64

The problem is that we haven't placed a bootstrap for openbsd-ppc64. This should be quick for us to fix. I'll work on it.

Here is the latest message from the swarming bot on openbsd-ppc64-n2vi:
28106 2024-05-13 02:23:34.925 E: Unable to open given url, https://chromium-swarm.appspot.com/swarming/api/v1/bot/poll, after 1 attempts or 240 timeout.
500 Server Error: Internal Server Error for url: https://chromium-swarm.appspot.com/swarming/api/v1/bot/poll
Alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Content-length: 228
Content-type: text/html; charset=UTF-8
Date: Mon, 13 May 2024 02:23:34 GMT
Server: Google Frontend
500 Internal Server Error
The server has either erred or is incapable of performing the requested operation.

28106 2024-05-13 02:23:34.925 E: Swarming poll error: Failed to contact server

Does that error happen only occasionally or does it persist even after restarts?
If the former, please try it again now that CL 584975 has landed.
It should resolve the error we saw in https://github.com/golang/go/issues/63480#issuecomment-2105269618 on Friday.

Ok, killed the bootstrapswarm and python processes, restarted with the usual (benign?) startup messages at 15:57:05 UTC, but see nothing more yet from the bootstrapswarm output. The Builders dashboard for INFRA says "Task did not start, no resource". I don't know if we're waiting for something to restart on a server somewhere or what.
I feel like I'm just stumbling around in the dark here. It might be you only need to point me to some doc that expands on "try it again now". The full LUCI documentation from chromium.org is a bit much to digest since I don't have much server side insight.

I see that the builder is now working on the build https://ci.chromium.org/b/8748038859820104945, which is looking promising. The "Task did not start, no resource" entries you saw are probably slightly older, from before you restarted it.

That build got pretty far, up to "ok  	runtime	66.123s" with tests passing. But it seems to have failed due to being out of memory afterwards. It also took about 11 min to run make.bash, and 28 min to run (partial) tests. Other openbsd builders have slow multipliers set here, it seems we should do something similar here if this performance is working as intended.

Sure, set the multiplier if you want. Power9 processors are not inherently slow, but no telling what layers of inefficiency there may be in all this. The same 8-core machine is running bootstrapswarm and the gopher buildlet; to me, the load average of 14 to 18 does seem like a lot.
We're not actually out of RAM; the machine has 23GB free at the moment. But there may be some ulimits that need to be adjusted somewhere. I did configure the login class to give these more than openbsd's default small values but I'm not sure how much you need.

Thanks. I think you should let the LUCI version of the builder run for some time, and when it seems stable, feel free to stop the coordinator instance to free up the resources. The only reason to keep the coordinator instance is if you're not quite ready to switch yet, but it needs to happen at some point since the coordinator will be going away.
I'll update CL 585217 to give it a timeout scale for now, especially since it's running builds for both LUCI and coordinator, and we can adjust it later on as it becomes more clear what the optimal value is.

This eventually panic'd the kernel with an allocation failure.
Restarting now to see how reproducible this is.

Still wasn't seeing anything running, so killed off the python and bootstrapswarm processes and restarted.
They just report status code 401 and immediately exit. I'm not illuminated by looking at the Ended Builds list either.

Thanks for working on this.

I'm not illuminated by looking at the Ended Builds list either.

I failed to realizer this sooner, but our configuration intends to make it possible for you to see the machine pool (see "poolViewer" granted to group "all" here).
I believe it currently requires you to sign in (any account will work), then you can view the contents of the "Machine Pool" links such as https://chromium-swarm.appspot.com/botlist?f=cipd_platform%3Aopenbsd-ppc64&f=pool%3Aluci.golang.shared-workers. You should see something like this:

And clicking on the bot name will take you to https://chromium-swarm.appspot.com/bot?id=openbsd-ppc64-n2vi where you'll find more information about its current state from LUCI's perspective. Apologies about the additional overhead at this time to get to this information.

Since you've done some restarts, it might help to confirm that luci_machine_tokend process still working as described in step 4 of https://go.dev/wiki/DashboardBuilders#how-to-set-up-a-builder-1, and that the token file it writes to has new content, which is propagated to bootstrapswarm.
If that isn't where the problem is, is there more information included in the status code 401 message, beyond "Downloading the swarming bot" and "status code 401"? Also, is there more useful context in the local swarming bot log?

sign in (any account will work)
Thanks, that was a crucial clue. I'd tried signing in before, but was put off by the "grant write access to all your git repositories" warning. Doing it with a less powerful account is fine.

Now that the bot is getting work again we'll see if we can reproduce the pagedaemon kernel panic. Not that I'm a kernel developer by any means, but gotta learn sometime! I recognize that this is a sufficiently unusual platform and workload that it is not inconceivable that we step on a new corner case.

No kernel crashes yet, just running all the way to Failure. :)
I'm still trying to understand more about the build output, in particular the details of what "resource temporarily unavailable" means specifically. Is it running into a user process limit for forking? The login.conf here sets maxproc-max=256, maxproc-cur=128. Do the tests need more processes than that?
One probably unrelated item caught my eye: /var/log/secure reports

May 15 20:48:40 t doas: command not permitted for swarming: chmod 0777 /home/swarming/.swarming/w/ir/x/t/go-build3552889220

All those files are already owned by user "swarming" so why would the software be trying to become root?
I do recall seeing (and being horrified by) all.bash trying to become root. That's when I switched to only running make.bash on most of my machines. It is ok here on t.n2vi.net=openbsd-ppc64-n2vi for you to be root if you have to; I'm assuming arbitrarily bad stuff may happen when running a builder machine. Just let me know if you really need it.

Overnight, we captured another kernel panic that closely resembles the earlier one. I'll get back to you when I make progress on this; may be quite a while. LUCI appropriately marks me as offline for the duration.

status update; no need to respond...
Found a recent patch to openbsd powerpc64 pagedaemon pmac.c that may be relevant, so upgraded t.n2vi.net from -stable to -snapshot.
Now the previously-ok luci_machine_tokend dumps core with a pinsyscalls error on the console, so rebuilt with the nineteen-line install sequence from https://pkg.go.dev/go.chromium.org/luci and a freshly compiled go1.22.3. This now seems to be generating a new token.json ok.
Rebuilt and restarted bootstrapswarm. The LUCI Builders dashboard shows the machine now as Idle; based on past experience, in an hour or two it will actually start delivering work without further attention. I'll periodically monitor to be sure that happens, and then over the next couple days we'll see if the kernel panic re-occurs.

I do suspect we're stepping on a pagedaemon bug that occasionally crashes
the machine, but it is getting LUCI work enough done that perhaps Gophers
can make their own independent progress while I pursue the OpenBSD issue.
On Fri, May 17, 2024, 16:48 Eric Grosse @.***> wrote:

status update; no need to respond...
Found a recent patch to openbsd powerpc64 pagedaemon pmac.c that may be
relevant, so upgraded t.n2vi.net from -stable to -snapshot.
Now the previously-ok luci_machine_tokend dumps core with a pinsyscalls
error on the console, so rebuilt with the nineteen-line install sequence
from https://pkg.go.dev/go.chromium.org/luci and a freshly compiled
go1.22.3. This now seems to be generating a new token.json ok.
Rebuilt and restarted bootstrapswarm. The LUCI Builders dashboard shows
the machine now as Idle; based on past experience, in an hour or two it
will actually start delivering work without further attention. I'll
periodically monitor to be sure that happens, and then over the next couple
days we'll see if the kernel panic re-occurs.
—
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/63480#issuecomment-2118498598, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACADPOXZT27J2RRAXAVRBXLZC2JL7AVCNFSM6AAAAAA5ZVVAZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJYGQ4TQNJZHA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Restarted swarm with twice the process ulimit. Let's see if that reduces the number of fork/exec failures.
No recent crashes, happily.

My builder machine is fine, no crashes, but I see that the dashboard thinks it is offline. Here is a tail -50 nohup.out. I believe the ball is back in your court...
Traceback (most recent call last):
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/bot_main.py", line 1831, in rbe_poll
    self._rbe_session = remote_client.RBESession(
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/remote_client.py", line 901, in __init__
    resp = remote.rbe_create_session(dimensions, bot_version,
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/remote_client.py", line 587, in rbe_create_session
    raise RBEServerError('Failed to create RBE session, see bot logs')
bot_code.remote_client_errors.RBEServerError: Failed to create RBE session, see bot logs
38455 2024-05-22 18:26:05.889 E: Unable to open given url, https://chromium-swarm.appspot.com/swarming/api/v1/bot/rbe/session/create, after 1 attempts or 240 timeout.
429 Client Error: Too Many Requests for url: https://chromium-swarm.appspot.com/swarming/api/v1/bot/rbe/session/create
----------
Alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Content-length: 284
Content-type: text/plain; charset=utf-8
Date: Wed, 22 May 2024 18:26:05 GMT
Server: Google Frontend

rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Create Bot Session requests per project' and limit 'Create Bot Session requests per project per minute per region' of service 'remotebuildexecution.googleapis.com' for consumer 'project_number:575346572923'.

----------
38455 2024-05-22 18:26:05.889 E: Failed to open RBE Session: Failed to create RBE session, see bot logs
Traceback (most recent call last):
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/bot_main.py", line 1831, in rbe_poll
    self._rbe_session = remote_client.RBESession(
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/remote_client.py", line 901, in __init__
    resp = remote.rbe_create_session(dimensions, bot_version,
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/remote_client.py", line 587, in rbe_create_session
    raise RBEServerError('Failed to create RBE session, see bot logs')
bot_code.remote_client_errors.RBEServerError: Failed to create RBE session, see bot logs
38455 2024-05-22 18:26:09.744 E: Unable to open given url, https://chromium-swarm.appspot.com/swarming/api/v1/bot/rbe/session/create, after 1 attempts or 240 timeout.
429 Client Error: Too Many Requests for url: https://chromium-swarm.appspot.com/swarming/api/v1/bot/rbe/session/create
----------
Alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Content-length: 284
Content-type: text/plain; charset=utf-8
Date: Wed, 22 May 2024 18:26:09 GMT
Server: Google Frontend

rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Create Bot Session requests per project' and limit 'Create Bot Session requests per project per minute per region' of service 'remotebuildexecution.googleapis.com' for consumer 'project_number:575346572923'.

----------
38455 2024-05-22 18:26:09.744 E: Failed to open RBE Session: Failed to create RBE session, see bot logs
Traceback (most recent call last):
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/bot_main.py", line 1831, in rbe_poll
    self._rbe_session = remote_client.RBESession(
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/remote_client.py", line 901, in __init__
    resp = remote.rbe_create_session(dimensions, bot_version,
  File "/home/swarming/.swarming/swarming_bot.1.zip/bot_code/remote_client.py", line 587, in rbe_create_session
    raise RBEServerError('Failed to create RBE session, see bot logs')
bot_code.remote_client_errors.RBEServerError: Failed to create RBE session, see bot logs

The error message above includes "quota exceeded". It seems to have been temporary. Looking at https://ci.chromium.org/ui/p/golang/g/port-openbsd-ppc64/builders, the builder seems to be stable and passing in the main Go repo and all golang.org/x repos. Congratulations on reaching this point!
Would you like to remove its known issue as the next step?

We got another pager daemon kernel crash last night. I'm glad we'r getting substantial test runs done, but we're not out of the woods yet.

I see a "context deadline exceeded" failure in the latest build. Not sure how to interpret that, but FYI as part of debugging the kernel crashes I've changed some kernel memory barriers that possibly slow page mapping changes a bit. I don't expect any large impact on system speed overall, but I'm unsure.

I've been able to reproduce a kernel panic without anything involving Go, so will be pursuing that and temporarily not running swarm. I'll update here when we've made progress with the kernel.

Although the kernel issue is not fully solved, I'm satisfied that it is sufficiently understood and being worked on in Mac Studio locking bug. I now regard the LUCI migration as complete for openbsd-ppc64 builder and am no longer running the buildlet there. As long as we keep the machine load at a reasonable level, we're rarely triggering the kernel lock issue.
@dmitshur Thanks again for all your help with this. You may remove
knownissue
for me if you like. I would submit a CL myself except that the machine with my GitHub login is too locked down to import all the luciconfig toolchain. I'll think about how to get around that eventually.

I regret to say that my comment seems to have jinxed things. After the change, openbsd-ppc64 builder is crashing more frequently again.
Anyway, let's leave things be for a couple weeks while y'all are at GopherCon and OpenBSD works on locks.

Following up here as some time has passed and the builder appears to have been doing well recently. @n2vi Okay to submit CL 596817 to mark this builder as complete? (If desired, it's always possible to open a new, more narrow known issue.)

Sure.
As my system kernel friends say, multicore MMU is an art. I believe there are remaining bugs encountered when under high load, but I reboot the server when needed.


Autocomplete not working on some iPhones/versions of iOS

Problem description
Autocomplete dropdown does not appear on some versions of iOS + Safari. We've tested on multiple iPhone/iOS versions and bug is inconsistent. Bug does not appear with iOS emulators but it has appeared on iPhone 6+ and 6s devices. We've tested on multiple versions of Material-UI and it has appeared on 0.16.7 and up.
Link to minimal working code that reproduces the issue
Bug appears with the sample code on the documentation website
Versions

Material-UI:  0.16.7 and up
React:
Browser: Safari 10

@Taakn I can't see anything obvious in the 0.16.7 release notes that would impact this: https://github.com/callemall/material-ui/releases/tag/v0.16.7
git bisect around that release may be the way to go.

So I went through some extensive testing to try and figure out exactly what versions of iOS or iPhones were affected. Here are my findings:

I went to an Apple Store and tested there on all the iPhone models I could find (5, 6 and 7 & S/Plus). I am confirming that the autocomplete does not work on any devices on 0.17.2.

I tested on one particular iPhone 6s and I am confirming that autocomplete does not work on any versions 0.16.0 and up (haven't tested lower), and does not work on any browsers (Safari, Chrome and Firefox).

Looks like the popup appears but is not positioned underneath the input. It might be related to https://github.com/callemall/material-ui/issues/3638

@taakan I just tested AutoComplete on the docs site on 5s, and it seems fine. I'm sure if the problem was that widespread since 0.16.7 we'd have heard before now...

Once again it worked on another iPhone 6 (regular, not S or Plus). So the bug seems to depend on some parameter I haven't identfied yet. I've spent several hours this afternoon finding different iPhones and going to an Apple Store to test, so up to you if you want to dismiss it like that

so up to you if you want to dismiss it like that

@Taakn No need for the snark.; that is a good way to get your issue dismissed.

Once again it worked on another iPhone 6

At no point have you mentioned that, only that it works on emulators. In fact, you specifically mentioned that it didn't work on the iPhone 6 in the Apple Store.
What version of iOS is the working iPhone 6 running? Have you considered that this might be an iOS 10.3 issue, which would explain why it works on iPhone and not another? That would also explain why it's a recent issue.


clearFilter doesn not clear the search panel in gridView

I tried to clear gird using clearFilter()  method .
It clears all the filters of a specific type applied to grid records but does not clear the search panel .
You can see the bug in the below page as well:
https://js.devexpress.com/Demos/WidgetsGallery/#demo/data_grid-filtering_and_sorting-filtering
many thanks

Hello,
It looks like this issue is not related to the devextreme-angular 2 integration. Please redirect your question to our DevExpress Support Center.

Could you please clarify, whether the limitation is with Angular 2 wrapper code (available here) around the underlying javascript grid api or is this a limitation in the javascript grid or api?

Since the issue can be reproduced without devextreme-angular 2 integration, it is related only to our DevExtreme project.

Thanks
I will redirect my question to DevExpress support  team .


Deserialization Error for SteamVR_Action

Hey,
I have lately encountered an issue concerning the deserialization of an SteamVR_Action_Boolean quite similar to an issue i have submitted before. I have an action set handtool with a boolean teleport that is defined in the inspector. When starting the application, SteamVR seems to seek the default teleport action default/in/teleport (which I deleted as we don't use it), fails and sets the teleportAction field to null. Obviously this results in errors spamming the console.
Teleport Inspector during Edit mode:

After entering play mode:

As a workaround, you can delete the auto assignment in Teleport.cs, line 16:
public SteamVR_Action_Boolean teleportAction = SteamVR_Input.GetAction<SteamVR_Action_Boolean>("Teleport");

to
public SteamVR_Action_Boolean teleportAction;

Strangely, this doesn't seem to happen all the time.

I have also seen this a lot. I have two components, one for the left hand, one for the right hand. And half my actions (all of the actions that belong to a non-default Action Set) frequently get removed from the second controller. The first always keeps them all.
In my case, there is actually little use of even having those in the Inspector, so I simply declared them all private which fixes all my problems with this issue.
The initialization code that I'm using is this:
private SteamVR_Action_Boolean actionPlayingSkip = SteamVR_Actions.playing.Skip;
... and this eventually calls this:
       public CreateType GetCopy<CreateType>() where CreateType : SteamVR_Action, new()         {             if (SteamVR_Input.ShouldMakeCopy()) //no need to make copies at runtime             {                 CreateType action = new CreateType();                 action.InitializeCopy(this.actionPath, this.GetSourceMap());                 return action;             }             else             {                 return (CreateType)this;             }         }
(that's in SteamVR_Action.cs) ... maybe something's going wrong with this when used together with serialization? I haven't checked the code path for GetAction<SteamVR_Action_Boolean>(string) but if it's the same, that might be what's going wrong there.

I believe this has been fixed since this post was made. If not, please create a new issue with the repro steps and ideally an example project to replicate the issue. Thanks!


fix: Support for custom HTTP headers. Fixes #7985

Signed-off-by: Todor Todorov<EMAIL_ADDRESS>Fixes #7985
Here is an example when I configure Argo Workflows behind Cloudflare Access and I don't set any header:
$ ./argo list -A
FATA[2022-02-25T13:44:46.653Z] invalid character '<' looking for beginning of value

Here is an example when I configure Argo Workflows behind Cloudflare Access and I set cf-access-token header:
$ export DOMAIN=argo-wf.example.com
$ cloudflared access token -app=https://$DOMAIN
$ ./argo -H "cf-access-token:$(cloudflared access token -app=https://$DOMAIN)" list -A
NAMESPACE     NAME                    STATUS      AGE   DURATION   PRIORITY
argo-events   eample-workflow-fsx8t   Succeeded   15h   52m        0
argo-events   eample-workflow-v9zrf   Succeeded   16h   3m         0
argo-events   eample-workflow-9r2q5   Succeeded   17h   1m         0
argo-events   eample-workflow-48ssl   Succeeded   17h   28m        0
argo-events   eample-workflow-pd9xd   Succeeded   18h   32m        0

Lgtm


Cannot Print Images in Edge

Images can be printed before fix but not after fix. See demo page.

There's no fix for that unfortunately

Couldn't you add some print CSS? Something like this. (although I'm not actually sure what CSS is stopping it currently)
@media print {
   img {
    display: block;
    position: relative;
  }
}

The issue is that the images are actually replaced by transparent PNGs and what you see is a background-image, which is normally not printed by browsers.
I'm leaving this open in case anybody knows how to change this behavior, but I don't think it's possible.
Print-specific CSS doesn't change the fact that images are actually transparent and not the ones you have set in your HTML

This might actually be possible: https://twitter.com/dudleystorey/status/813446282534617089
I'm open to PRs

That does work, but the images will be stretched because this can only work by undoing the polyfill
	// this was added at the end of my fix() function
	if (!enabledPrints && window.matchMedia) {
		enabledPrints = true;
		matchMedia('print').addListener(mql => {
			const images = document.querySelectorAll('img');
			for (let i = 0; i < images.length; i++) {
				if (images[i][OFI] && images[i][OFI].img) {
					if (mql.matches) {
						images[i].parentNode.replaceChild(images[i][OFI].img, images[i]);
					} else {
						// images[i].img.parentNode.replaceChild(images[i][OFI], images[i].img);
					}
				}
			}
		});
	}

And to fix that the layout of your site might break. I think it causes more trouble than it's worth :/

I added some more info in my first comment


Add Transcriber object.

This will be the core of the new firethings project. It is responsible for connecting pins to the cloud and the cloud to pins.

Added the Portal.{h,cc} changes in here as well. Seemed easier since dependent PRs are hard to parse (too much noise).

oh nooo :)

Ya smaller PRs are better but I haven't figured out a good workflow for depending PRs yet that aren't a mess to review and merge.

I haven't figured out a good workflow for depending PRs yet that aren't a mess to review and merge.

having them in two different (but dependent) branch and using rebase worked well for me in the past. But LGTM :)


[ISSUE-110] ShuffleWriteTime should include pushMergeData

[BUG]/[FEATURE] title
What changes were proposed in this pull request?
Why are the changes needed?

What are the items that need reviewer attention?
Related issues.
Related pull requests.
How was this patch tested?
/cc @related-reviewer
/assign @main-reviewer

@waitinfuture

LGTM. Thanks.


Fix for the EnsureReactLoaded method of React.JavaScriptEngineFactory class

Hello!
The following line of code:
var result = engine.CallFunction<string[]>("ReactNET_initReact");

Will always cause an error:
System.ArgumentException: The type of return value `System.String[]` is not supported.

This error occurs, because the JavaScript Engine Switcher only supports primitive types. Here is a quote from the documentation:

The supported .NET types are as follows:

JavaScriptEngineSwitcher.Core.Undefined
System.Boolean
System.Int32
System.Double
System.String

This PR contains the simplest fix for this error.

Thanks @Taritsyn. I tested this before merging, not sure how I did not see this error. Will do some digging later to see what happened.

Probably another reason why we need more integration tests - I suspect this functionality is mocked out in all the automated tests. I'll push a beta version with this fix later today.

@dustinsoftware This error really passes all the tests. I was able to reproduce it only using the following setting:
ReactSiteConfiguration.Configuration
	…
	.SetLoadReact(false)
	…
	;

I'll see if we can get a simple test added that doesn't require Browserstack or Selenium for the server-rendering pipeline. The React.Sample.CoreMvc project runs fine, but the React.Sample.Router.CoreMvc sample does not (which depends on a bundled copy of React).
I confirmed that @Taritsyn's fix works with the router sample.

@dustinsoftware It should be possible to test the server-side rendering as long as a JS engine works on AppVeyor (which it should). We just need to have some tests that do not mock out the JS engine.


scripts: add a task for testing mlibc sysdeps like on CI

Addressed the issues raised. Also updated the path for the kernel headers that are passed to the script.


Unexpected forwarding timeout when the system pressure is low

RaftKeeper version
v2.1.1
Description

follower1
2024.09.04 02:27:28.450203 [ 96 ] <Warning> RequestForwarder: Forward request #User#2031#1002562415 timeout
2024.09.04 02:27:28.450231 [ 96 ] <Warning> RequestProcessor: Found error request #0x7ef#1002562415#Remove accepted:false error_code:-2
2024.09.04 02:27:28.450286 [ 56 ] <Warning> RequestProcessor: Not found error request #0x7ef#1002562415#Remove accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 02:51:29.757679 [ 104 ] <Warning> RequestForwarder: Forward request #User#2051#897306435 timeout
2024.09.04 02:51:29.757704 [ 104 ] <Warning> RequestProcessor: Found error request #0x803#897306435#Create accepted:false error_code:-2
2024.09.04 02:51:29.757760 [ 56 ] <Warning> RequestProcessor: Not found error request #0x803#897306435#Create accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 04:10:48.371145 [ 93 ] <Warning> RequestForwarder: Forward request #User#2058#791636908 timeout
2024.09.04 04:10:48.371193 [ 93 ] <Warning> RequestProcessor: Found error request #0x80a#791636908#Multi accepted:false error_code:-2
2024.09.04 04:10:48.371310 [ 56 ] <Warning> RequestProcessor: Not found error request #0x80a#791636908#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 04:45:57.943673 [ 93 ] <Warning> RequestForwarder: Forward request #User#2058#793238364 timeout
2024.09.04 04:45:57.943708 [ 93 ] <Warning> RequestProcessor: Found error request #0x80a#793238364#Multi accepted:false error_code:-2
2024.09.04 04:45:57.943768 [ 56 ] <Warning> RequestProcessor: Not found error request #0x80a#793238364#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 06:45:48.927674 [ 96 ] <Warning> RequestForwarder: Forward request #User#2047#907929485 timeout
2024.09.04 06:45:48.927703 [ 96 ] <Warning> RequestProcessor: Found error request #0x7ff#907929485#Multi accepted:false error_code:-2
2024.09.04 06:45:48.927766 [ 56 ] <Warning> RequestProcessor: Not found error request #0x7ff#907929485#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 07:05:16.180588 [ 99 ] <Warning> RequestForwarder: Forward request #User#2038#968536106 timeout
2024.09.04 07:05:16.180622 [ 99 ] <Warning> RequestProcessor: Found error request #0x7f6#968536106#Multi accepted:false error_code:-2
2024.09.04 07:05:16.180691 [ 56 ] <Warning> RequestProcessor: Not found error request #0x7f6#968536106#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 08:22:58.275716 [ 93 ] <Warning> RequestForwarder: Forward request #User#2058#803805465 timeout
2024.09.04 08:22:58.275746 [ 93 ] <Warning> RequestProcessor: Found error request #0x80a#803805465#Multi accepted:false error_code:-2
2024.09.04 08:22:58.275798 [ 56 ] <Warning> RequestProcessor: Not found error request #0x80a#803805465#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.

follower2
2024.09.03 21:38:21.128696 [ 96 ] <Warning> RequestForwarder: Forward request #User#2053#868134746 timeout
2024.09.03 21:38:21.128728 [ 96 ] <Warning> RequestProcessor: Found error request #0x805#868134746#Multi accepted:false error_code:-2
2024.09.03 21:38:21.128791 [ 54 ] <Warning> RequestProcessor: Not found error request #0x805#868134746#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.03 22:50:45.386748 [ 96 ] <Warning> RequestForwarder: Forward request #User#2053#871263725 timeout
2024.09.03 22:50:45.386782 [ 96 ] <Warning> RequestProcessor: Found error request #0x805#871263725#Multi accepted:false error_code:-2
2024.09.03 22:50:45.386840 [ 54 ] <Warning> RequestProcessor: Not found error request #0x805#871263725#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 00:04:29.677325 [ 92 ] <Warning> RequestForwarder: Forward request #User#2049#901054523 timeout
2024.09.04 00:04:29.677352 [ 92 ] <Warning> RequestProcessor: Found error request #0x801#901054523#Multi accepted:false error_code:-2
2024.09.04 00:04:29.677411 [ 54 ] <Warning> RequestProcessor: Not found error request #0x801#901054523#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 00:34:07.876210 [ 95 ] <Warning> RequestForwarder: Forward request #User#2036#959245176 timeout
2024.09.04 00:34:07.876239 [ 95 ] <Warning> RequestProcessor: Found error request #0x7f4#959245176#Multi accepted:false error_code:-2
2024.09.04 00:34:07.876292 [ 54 ] <Warning> RequestProcessor: Not found error request #0x7f4#959245176#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.
2024.09.04 08:54:16.162751 [ 100 ] <Warning> RequestForwarder: Forward request #User#2025#1053668331 timeout
2024.09.04 08:54:16.162780 [ 100 ] <Warning> RequestProcessor: Found error request #0x7e9#1053668331#Multi accepted:false error_code:-2
2024.09.04 08:54:16.162831 [ 54 ] <Warning> RequestProcessor: Not found error request #0x7e9#1053668331#Multi accepted:false error_code:-2 in pending queue. Possible reason: 1. request forwarding error; 2.close requests from deadSessionCleanThread are not put into pending queue; 3.error occurs(forward or append entries) but request is still committed, 'processCommittedRequest' may delete request from pending request first, so here we can not find it. We also delete it from errors.

How to reproduce

Please provide the write request qps information.

@JackyWoo The response of the forward request is unnecessary because once the leader receives a write request, it will do log replication to the follower. There are two possible scenarios: one is a timeout, and the other is that the CommittedRequest does not match the first request in the local PendingRequests. This indicates that the first request of PendingRequests was not received by the leader. We can handle this in processCommittedRequest and then send a failure response to the user.

ok, but we should resolve why follower does not received the response first.


wrong paper link

the link of this paper is wrong:
(arXiv 2024.03) Exploring the Potential of Large Language Models in Graph Generation

Fixed. Thank you for pointing that out.


Fix "linting" action

/regenerate-cache

I'm making an executive decision to merge this as it's succeeding in fixing the linting action
The workshops homepage should still work, accessible in the PR build from this link: https://openff-docs--37.org.readthedocs.build/en/37/workshops/2024


OIC: Response to request cannot be transmitted asynchronously

Issue Description
If you run the client/server pair from #2110 in sync, the put request completes successfully, but if you run it in async, you get
WRN:sol-coap ./src/lib/comms/sol-coap.c:805 on_can_write() Could not send packet 347 to  (0): Success

on the server side.
Steps to reproduce

Build the files pasted into #2110
Run the server in one terminal
Run the client in another terminal with parameters /a/xyzzy async

At this point, on the server you will see the above-mentioned warning and the client will fail to display the string putRequest complete. If you repeat the above steps but replace async with sync then the put request completes.

I tested this on top of master and I couldn't reproduce the problem. Both cases, async and sync, are working for me. Can you provide me with extra information? What branch have you used?

The async case:
client:
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/etc//soletta/boards/] to iterate: No such file or directory
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/usr/share//soletta/boards/] to iterate: No such file or directory
DBG:sol-platform ./src/lib/common/sol-platform.c:204 sol_platform_get_board_name() board name is unknown
DBG:sol-update ./src/lib/common/sol-update.c:106 get_first_module_on_dir() Invalid update module dir: /home/nix/iot/soletta/build/soletta_sysroot//usr/lib/soletta/modules//update/
DBG:sol-update ./src/lib/common/sol-update.c:138 load_update_module() No update module to load
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:223 sol_init() Soletta 0.0.1 on linux-4.4.9-300.fc23.x86_64 initialized
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:262 sol_run() run
DBG:sol-coap ./src/lib/comms/sol-coap.c:1855 sol_coap_server_new_full() New server 0x796fa0 on port 0
WRN: ./src/lib/comms/sol-socket.c:54 sol_socket_ip_new() DTLS is not enabled, secure socket is not possible
WRN:sol-coap ./src/lib/comms/sol-coap.c:1802 sol_coap_server_new_full() Could not create socket (38): Function not implemented
INF: ./src/lib/comms/sol-oic-client.c:1440 sol_oic_client_new() DTLS support not built-in, only making non-secure requests
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=1) -- payload of 20 bytes, buffer holding it with 32 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 31058, href: '/oic/res', type: 1, header_code: 1, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 31058, href: '', type: 1, header_code: 69, query: ''}
resourceFound: /oic/d
resourceFound: /oic/p
resourceFound: /a/xyzzy
DBG: ./src/lib/comms/sol-oic-client.c:148 _best_server_for_resource() Resource does not have secure flag and we do not have DTLS support (using port 5683)
DBG: ./src/lib/comms/sol-oic-client.c:1113 _resource_request() Sending CoAP packet through non-secure server (port 5683)
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 31058, href: '', type: 1, header_code: 69, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:712 timeout_expired() waiting 2345 ms to re-try packet id 13926
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=1) -- payload of 32 bytes, buffer holding it with 128 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 13926, href: '/a/xyzzy', type: 0, header_code: 3, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:632 timeout_cb() server 0x796fa0 retrying packet id 13926 to client ::ffff:<IP_ADDRESS>
DBG:sol-coap ./src/lib/comms/sol-coap.c:712 timeout_expired() waiting 4690 ms to re-try packet id 13926
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=1) -- payload of 32 bytes, buffer holding it with 128 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 13926, href: '/a/xyzzy', type: 0, header_code: 3, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:632 timeout_cb() server 0x796fa0 retrying packet id 13926 to client ::ffff:<IP_ADDRESS>
DBG:sol-coap ./src/lib/comms/sol-coap.c:712 timeout_expired() waiting 9380 ms to re-try packet id 13926
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=1) -- payload of 32 bytes, buffer holding it with 128 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 13926, href: '/a/xyzzy', type: 0, header_code: 3, query: ''}
^CDBG:sol-mainloop ./src/lib/common/sol-mainloop-impl-posix.c:237 on_sig_quit() got signal 2, quit main loop...
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:286 sol_quit_with_code() quit with code 0
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:303 sol_shutdown() shutdown
DBG:sol-update ./src/lib/common/sol-update.c:175 sol_update_shutdown() Update shutdown

server:
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/etc//soletta/boards/] to iterate: No such file or directory
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/usr/share//soletta/boards/] to iterate: No such file or directory
DBG:sol-platform ./src/lib/common/sol-platform.c:204 sol_platform_get_board_name() board name is unknown
DBG:sol-update ./src/lib/common/sol-update.c:106 get_first_module_on_dir() Invalid update module dir: /home/nix/iot/soletta/build/soletta_sysroot//usr/lib/soletta/modules//update/
DBG:sol-update ./src/lib/common/sol-update.c:138 load_update_module() No update module to load
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:223 sol_init() Soletta 0.0.1 on linux-4.4.9-300.fc23.x86_64 initialized
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:262 sol_run() run
DBG:sol-coap ./src/lib/comms/sol-coap.c:1855 sol_coap_server_new_full() New server 0x1906060 on port 5683
WRN: ./src/lib/comms/sol-socket.c:54 sol_socket_ip_new() DTLS is not enabled, secure socket is not possible
WRN:sol-coap ./src/lib/comms/sol-coap.c:1802 sol_coap_server_new_full() Could not create socket (38): Function not implemented
INF:sol-oic-server ./src/lib/comms/sol-oic-server.c:595 sol_oic_server_ref() DTLS support not built in, OIC server running in insecure mode
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 31058, href: '/oic/res', type: 1, header_code: 1, query: ''}
DBG:sol-oic-server ./src/lib/comms/sol-oic-server.c:464 _sol_oic_server_res() Ensuring OIC (cbor) payload of size 209
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 31058, href: '/oic/res', type: 1, header_code: 1, query: ''}
DBG:sol-oic-server ./src/lib/comms/sol-oic-server.c:464 _sol_oic_server_res() Ensuring OIC (cbor) payload of size 209
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=2, pending_len=0) -- payload of 224 bytes, buffer holding it with 256 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 31058, href: '', type: 1, header_code: 69, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=0) -- payload of 224 bytes, buffer holding it with 256 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 31058, href: '', type: 1, header_code: 69, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 13926, href: '/a/xyzzy', type: 0, header_code: 3, query: ''}
putRequest
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=0) -- payload of 12 bytes, buffer holding it with 16 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 13926, href: '', type: 2, header_code: 64, query: ''}
WRN:sol-coap ./src/lib/comms/sol-coap.c:805 on_can_write() Could not send packet 13926 to  (0): Success
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 13926, href: '/a/xyzzy', type: 0, header_code: 3, query: ''}
putRequest
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=2, pending_len=0) -- payload of 12 bytes, buffer holding it with 16 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 13926, href: '', type: 2, header_code: 64, query: ''}
WRN:sol-coap ./src/lib/comms/sol-coap.c:805 on_can_write() Could not send packet 13926 to  (0): Success
^CDBG:sol-mainloop ./src/lib/common/sol-mainloop-impl-posix.c:237 on_sig_quit() got signal 2, quit main loop...
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:286 sol_quit_with_code() quit with code 0
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:303 sol_shutdown() shutdown
DBG:sol-update ./src/lib/common/sol-update.c:175 sol_update_shutdown() Update shutdown

The sync case:
client:
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/etc//soletta/boards/] to iterate: No such file or directory
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/usr/share//soletta/boards/] to iterate: No such file or directory
DBG:sol-platform ./src/lib/common/sol-platform.c:204 sol_platform_get_board_name() board name is unknown
DBG:sol-update ./src/lib/common/sol-update.c:106 get_first_module_on_dir() Invalid update module dir: /home/nix/iot/soletta/build/soletta_sysroot//usr/lib/soletta/modules//update/
DBG:sol-update ./src/lib/common/sol-update.c:138 load_update_module() No update module to load
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:223 sol_init() Soletta 0.0.1 on linux-4.4.9-300.fc23.x86_64 initialized
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:262 sol_run() run
DBG:sol-coap ./src/lib/comms/sol-coap.c:1855 sol_coap_server_new_full() New server 0xfddfa0 on port 0
WRN: ./src/lib/comms/sol-socket.c:54 sol_socket_ip_new() DTLS is not enabled, secure socket is not possible
WRN:sol-coap ./src/lib/comms/sol-coap.c:1802 sol_coap_server_new_full() Could not create socket (38): Function not implemented
INF: ./src/lib/comms/sol-oic-client.c:1440 sol_oic_client_new() DTLS support not built-in, only making non-secure requests
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=1) -- payload of 20 bytes, buffer holding it with 32 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 55905, href: '/oic/res', type: 1, header_code: 1, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 55905, href: '', type: 1, header_code: 69, query: ''}
resourceFound: /oic/d
resourceFound: /oic/p
resourceFound: /a/xyzzy
DBG: ./src/lib/comms/sol-oic-client.c:148 _best_server_for_resource() Resource does not have secure flag and we do not have DTLS support (using port 5683)
DBG: ./src/lib/comms/sol-oic-client.c:1113 _resource_request() Sending CoAP packet through non-secure server (port 5683)
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 55905, href: '', type: 1, header_code: 69, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:712 timeout_expired() waiting 2345 ms to re-try packet id 49930
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=1) -- payload of 32 bytes, buffer holding it with 128 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 49930, href: '/a/xyzzy', type: 0, header_code: 3, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 49930, href: '', type: 2, header_code: 64, query: ''}
put request complete
DBG:sol-coap ./src/lib/comms/sol-coap.c:1440 remove_outgoing_confirmable_packet() Received ACK for packet id 49930
^CDBG:sol-mainloop ./src/lib/common/sol-mainloop-impl-posix.c:237 on_sig_quit() got signal 2, quit main loop...
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:286 sol_quit_with_code() quit with code 0
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:303 sol_shutdown() shutdown
DBG:sol-update ./src/lib/common/sol-update.c:175 sol_update_shutdown() Update shutdown

server:
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/etc//soletta/boards/] to iterate: No such file or directory
INF: ./src/shared/sol-util-file.c:432 sol_util_iterate_dir() Could not open dir [/usr/share//soletta/boards/] to iterate: No such file or directory
DBG:sol-platform ./src/lib/common/sol-platform.c:204 sol_platform_get_board_name() board name is unknown
DBG:sol-update ./src/lib/common/sol-update.c:106 get_first_module_on_dir() Invalid update module dir: /home/nix/iot/soletta/build/soletta_sysroot//usr/lib/soletta/modules//update/
DBG:sol-update ./src/lib/common/sol-update.c:138 load_update_module() No update module to load
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:223 sol_init() Soletta 0.0.1 on linux-4.4.9-300.fc23.x86_64 initialized
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:262 sol_run() run
DBG:sol-coap ./src/lib/comms/sol-coap.c:1855 sol_coap_server_new_full() New server 0x1cf6060 on port 5683
WRN: ./src/lib/comms/sol-socket.c:54 sol_socket_ip_new() DTLS is not enabled, secure socket is not possible
WRN:sol-coap ./src/lib/comms/sol-coap.c:1802 sol_coap_server_new_full() Could not create socket (38): Function not implemented
INF:sol-oic-server ./src/lib/comms/sol-oic-server.c:595 sol_oic_server_ref() DTLS support not built in, OIC server running in insecure mode
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 55905, href: '/oic/res', type: 1, header_code: 1, query: ''}
DBG:sol-oic-server ./src/lib/comms/sol-oic-server.c:464 _sol_oic_server_res() Ensuring OIC (cbor) payload of size 209
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 55905, href: '/oic/res', type: 1, header_code: 1, query: ''}
DBG:sol-oic-server ./src/lib/comms/sol-oic-server.c:464 _sol_oic_server_res() Ensuring OIC (cbor) payload of size 209
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=2, pending_len=0) -- payload of 224 bytes, buffer holding it with 256 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 55905, href: '', type: 1, header_code: 69, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=0) -- payload of 224 bytes, buffer holding it with 256 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 55905, href: '', type: 1, header_code: 69, query: ''}
DBG:sol-coap ./src/lib/comms/sol-coap.c:1649 on_can_read() pkt received and parsed successfully
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 49930, href: '/a/xyzzy', type: 0, header_code: 3, query: ''}
putRequest
DBG:sol-coap ./src/lib/comms/sol-coap.c:796 on_can_write() CoAP packet sent (outgoing_len=1, pending_len=0) -- payload of 12 bytes, buffer holding it with 16 bytes
DBG:sol-coap ./src/lib/comms/sol-coap.c:2107 sol_coap_packet_debug() {id: 49930, href: '', type: 2, header_code: 64, query: ''}
^CDBG:sol-mainloop ./src/lib/common/sol-mainloop-impl-posix.c:237 on_sig_quit() got signal 2, quit main loop...
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:286 sol_quit_with_code() quit with code 0
DBG:sol-mainloop ./src/lib/common/sol-mainloop.c:303 sol_shutdown() shutdown
DBG:sol-update ./src/lib/common/sol-update.c:175 sol_update_shutdown() Update shutdown

@otaviobp I think outgoing->cliaddr is messed up if you transmit asynchronously.

@otaviobp I've dumped its contents as hex and when you run with sync, it has the same contents during both discovery and the request, but if you run with async its contents changes when attempting to send the response.

@otaviobp We need to copy cliaddr into the structure, instead of just storing a pointer to it, because cliaddr is a stack variable inside on_can_read() in sol-coap.c.

@otaviobp PTAL at #2125 :)


drivers: sensor: lis2dh: Implementation of FIFO mode

This commit enables support for using the internal hardware fifo of the
LIS2DH. This feature requires slightly unorthodox use of the sensor API:
Usually each call to sensor_sample_fetch() is followed by a single
sensor_channel_get() call but with LIS2DH_FIFO_MODE, the DRDY interrupt
won't arrive until the accelerometer has filled its internal FIFO. This
is 32 samples long, so the application needs to call
sensor_channel_get() 32 times.
This slight API abuse should however be weighed against the upside: when
using the FIFO, the host CPU needs to wake up much less frequently to
grab samples over i2c/spi which can lead to huge improvements in power
consumption.
Note: The LIS2DH sample can be augmented with a usage example in a
future commit if feedback is positive.
Signed-off-by: Benjamin Lindqvist<EMAIL_ADDRESS>

I really like this, the only negative I can think of is that the sensor has to manage a ring buffer. In this case its relatively small given the FIFO size and sensor involved. In faster/larger devices it'd be nice to feed the sensor buffers to fill and get them back as a whole in a ping/pong buffer like fashion I'd think. I could be wrong though!
Some folks may wish to see this option configured per driver instance using device tree, and that's understandable but for me this isn't a blocker.

I had it with just a raw buffer first but figured ppl would find this cleaner :D I kinda like the idea of zero copy into the app. I mean... The API is already implicitly device specific given that you have to loop call channel_get. So theres def argument for making an explicit API instead.

I'm going to redo this a bit, I think the better approach is to have the driver call the DRDY handler until all flushed samples are read out. This would impose no new device-specific code for the application and it would not violate the sensor.h API.
(I will also convert the Kconfig to a dts binding)


Add meta to all modules

After converting some of the modules to nf-core we had to add meta to the input/output channels.
Some of the modules that weren't migrated don't have meta, which makes us have to filter items from input and output channels.
We should modify all of the modules that are affected by this to include meta
Once these PRs get merged:
https://github.com/nf-core/nanostring/pull/114
https://github.com/nf-core/modules/pull/7108
https://github.com/nf-core/modules/pull/7100
FYI @alanmmobbs93

@alanmmobbs93 already taking care of this in https://github.com/nf-core/nanostring/pull/117


[BUG] VM hanging on restoring state when backup-target disconnected suddenly

Describe the bug
When restoring a VM and the backup-target suddenly disconnected, the VM will hang on restoring state and can not be deleted.
To Reproduce
Steps to reproduce the behavior:

Install Harvester with any nodes
Login to Dashboard then navigate to Advanced/Settings, setup backup-target with NFS or S3
Create Image for VM creation
Create VM vm1
Take Backup vm1b from vm1
Restore the backup vm1b to New/Existing VM
When the VM still in restoring state, update backup-target settings to Use the default value then setup it back.

Expected behavior
VM might not be able to restore successfully, but at least to be deleted successfully.
Environment:

Harvester ISO version: v1.0.3-rc1
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): qemu/KVM 3 nodes

Additional context
N/A

update to reproduce/often because I can delete the VM sometimes.

Hi @lanfon72, thanks for filing the issue. I will add a webhook to prevent user update backup-target when there is any in progressing VMBackup/VMRestore. If you want to simulate network issues, probably you need to cut off network on KVM. It's cause that updating backup-target, LH will try to remove old LH Backup on system.

Verified this bug has been fixed.

Test Information

Environment: qemu/KVM 2 nodes
Harvester Version: v1.0-fc72be9f-head
ui-source Option: Auto
ui-index URL: https://releases.rancher.com/harvester-ui/dashboard/release-harvester-v1.0/index.html

Verify Steps:

Install Harvester with any nodes
Navigate to Advanced/Settings and update ui-index to https://releases.rancher.com/harvester-ui/dashboard/release-harvester-v1.0/index.html and force refresh to make it applied.
Create a Image for VM creation
Create VM vm1 and add some files or execute ping <IP_ADDRESS> > hello
Setup backup-target

To simply the disconnection, you can setup a Minio for S3 target by executing docker run --name minis3 -dp 9000:9000 -p 9001:9001 minio/minio server /data --console-address ":9001"

Take a backup vm1b of VM vm1
Delete vm1
Restore vm1b into vm2, and Restore vm1b into vm3
Disconnect backup-target connection

Execute docker network disconnect bridge minis3 to disconnect the Minio container connection

Following Cafeterias should be fulfilled:

Delete vm2, it should be deleted successfully
Re-connect backup-target, vm3 should be restored successfully