Improve unit test coverage

In repository_service_tuf_worker/interfaces.py:
Made coverage ignore (# pragma: no cover) the interfaces' methods that have exceptions in the abstract classes as they will never be raised (a TypeError will be raised instead if an abstract method is not implemented).
The exceptions could be substituted with the "pass" keyword in IStorage(StorageBackendInterface) class, but to keep compatibility with the securesystemslib/storage.py implementation of StorageBackendInterface of the securesystemslib package, we keep it as is.
In tests/unit/tuf_repository_service_worker/services/storage/test_local.py:

Changed default stub value of version. Stubbed tests for LocalStorage.get should not have default stub for version equal to 1, because that's also the default value when a ValueError exception is called.
Added stubbing ValueError for max(versions), increasing coverage.

In repository_service_tuf_worker/repository.py there are still some unit tests that can be added (see the miss in coverage).
Closes #9
Signed-off-by: Konstantinos Papadopoulos<EMAIL_ADDRESS>

In repository_service_tuf_worker/repository.py there are still some unit tests that can be added (see the miss in coverage). I suggest creating a separate issue for them if we don't address them now (it needs a bit more investigation to test correctly those last parts).

Codecov Report
Base: 96.50% // Head: 99.34% // Increases project coverage by +2.83% :tada:

Coverage data is based on head (0824508) compared to base (001dabd).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #129      +/-   ##
==========================================
+ Coverage   96.50%   99.34%   +2.83%
==========================================
  Files           7        7
  Lines         458      456       -2
==========================================
+ Hits          442      453      +11
+ Misses         16        3      -13

Impacted Files
Coverage Δ

repository_service_tuf_worker/repository.py
98.94% <ø> (+1.04%)
:arrow_up:

repository_service_tuf_worker/interfaces.py
100.00% <100.00%> (+25.00%)
:arrow_up:

...itory_service_tuf_worker/services/storage/local.py
100.00% <0.00%> (+4.08%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Let me know if you need me to clear something up regarding this PR 😊

I will also make sure to review it today @KAUTH.
Sorry that it took so long to be reviewed.

I will have to continue tomorrow, but I only have one request:
in the future could you please split changes regarding a specific tool like coverage (in this example the # pragma: no cover for coverage) in a separate commit and all of the rest important changes in their own set of commits?

Sure thing!

It's better, but still, there is more work to be done for unit tests, especially in the repository_service_tuf_worker/repository.py. After your pr coverage tells me we have only 29% coverage of this file, but we don't have to fix everything here. One step at a time. :))

Thanks for the review once again @MVrachev!
By the way, I had also run the coverage report and saw a very different percentage:
Name                                                          Stmts   Miss  Cover
app.py                                                           43      0   100%
repository_service_tuf_worker/init.py                         8      0   100%
repository_service_tuf_worker/interfaces.py                      32      0   100%
repository_service_tuf_worker/repository.py                     284      4    99%
repository_service_tuf_worker/services/init.py                3      0   100%
repository_service_tuf_worker/services/keyvault/init.py       0      0   100%
repository_service_tuf_worker/services/keyvault/local.py         37      0   100%
repository_service_tuf_worker/services/storage/init.py        0      0   100%
repository_service_tuf_worker/services/storage/local.py          49      0   100%
TOTAL                                                           456      4    99%

@KAUTH appreciate that you renamed the variable.

It's better, but still, there is more work to be done for unit tests, especially in the repository_service_tuf_worker/repository.py. After your pr coverage tells me we have only 29% coverage of this file, but we don't have to fix everything here. One step at a time. :))

Thanks for the review once again @MVrachev!
By the way, I had also run the coverage report and saw a very different percentage:
Name Stmts Miss Cover app.py 43 0 100% repository_service_tuf_worker/init.py 8 0 100% repository_service_tuf_worker/interfaces.py 32 0 100% repository_service_tuf_worker/repository.py 284 4 99% repository_service_tuf_worker/services/init.py 3 0 100% repository_service_tuf_worker/services/keyvault/init.py 0 0 100% repository_service_tuf_worker/services/keyvault/local.py 37 0 100% repository_service_tuf_worker/services/storage/init.py 0 0 100% repository_service_tuf_worker/services/storage/local.py 49 0 100% TOTAL 456 4 99%

Strange. Here is my output.

Whatever the reason for that it shouldn't stop this pr from merging in the branch.
@KAUTH could you please do the same thing as I did in the screenshot and if there is any difference create an issue or ping me on email/slack?

@kairoaraujo do you want to rereview it again or should I merge it?

LGTM

Strange. Here is my output.

I don't see you running the tests before generating the coverage.
It's look ok for me as @KAUTH mentioned and the code of above.


Move table of contents to start of document.

It's not yet possible to specify the position of the table of contents when producing the PDF document. So instead, this PR modifies the structure of the document to fit the fixed location of the table of contents.

Allows the HTML & PDF versions to have the same structure.
Allows the lists of tables & examples to follow the table of contents in the PDF document.

Previews of the new structure are available at:

http://cf-metadata.github.io/moved-toc.html
http://cf-metadata.github.io/moved-toc.pdf

It's not clear whether this new structure is an improvement. Feedback welcome!

this is better from my point of view, as well as being consistent in html and pdf
I'll leave a little time for other comments before adoption

Thanks. I think your contents workround is sensible and looks satisfactory.

grand, let's go with this then


Investigate NGENing a subset of the .NET framework assemblies as a perf optimization

Investigate NGENing a subset of the .NET framework assemblies as a perf optimization in the upcoming versions of the Windows.  NGENing the entire .NET Framework comes with a cost of a substantially larger runtime image.  In the majority of usage scenarios, NGENing a subset of the .NET Framework will yield the same performance yet decrease the image size substantially.  For the smaller subset of scenarios which would be slower, it would be expected that users could NGEN the additional runtime assemblies that would benefit their scenario.

Closing as the investigation work is complete.


Make website ready to use

### Tasks
- [ ] getting started for designers (use content from sharepoint)
- [ ] getting started for dev (GitHub)
- [ ] Clean up comment documentation in code
- [ ] Create pages for components that are ready
- [ ] Add live example on component detail page
- [ ] Check stories of components for references to things we are fixing in this story.
- [ ] fix position of popovers (select + tooltip)🐨
- [ ] fix loading of icon 🐨

🐨 = Diana will work on this

Positioning of popover doesn't work when one of the parents is using css translate.

https://github.com/floating-ui/floating-ui/issues/1815

https://proud-water-0d02ee203-555.westeurope.2.azurestaticapps.net/


Error from transaction printed doesn't have any detail

Describe the bug
Currently printLogsAndFailures doesn't show any detail about error.
Usually it's something like Error: {"index":0}
Expected behavior
TransactionResult contains status.Failure with detail information.
Currently the way the information gets extracted is broken.

@ilblackdragon going to address as part of https://github.com/near/near-api-js/issues/331


Enable unstable 'test' crate

Surpresses error: use of unstable library feature 'test'

Cool, thanks very much!


v5: 401 api_key is missing

Hi getstream team,
Since the last update to v5.0.0, I got issue when retrieving feed_activity, with 401 status code api_key is missing.
I checked the breaking changes, I didnt find anything to change in my codebase.
  const getStreamClient = stream.default.connect(
    getStreamConfig.apiKey,
    getStreamConfig.apiSecret,
    getStreamConfig.apiId,
    { location: getStreamConfig.location },
  );

getStreamClient.feed(correlationType, correlationId);

await entity.get(JSON.parse(metadata));

hey @alexabidri, could you share the error stack or API response?
do you happen to have api_key passed as options to feed.get? something like:
getStreamClient.feed(correlationType, correlationId).get({api_key:null})

Relevant snippet is as following,
params: {
  api_key: this.apiKey,
  location: this.group,
  ...(kwargs.qs || {}),
},

if metadata in your snippet has apiKey as null, it will override.

I am only passing api_key, api_secret, app_id and location at startup of my service  with stream.connect
  const getStreamClient = stream.default.connect(
    getStreamConfig.apiKey,
    getStreamConfig.apiSecret,
    getStreamConfig.apiId,
    { location: getStreamConfig.location },
  );

const metadata = {
   reactions: { own: true, recent: true, counts: true },
   limit: 5,
   id_lt: 'e561de8f-00f1-11e4-b400-0cc47a024be0',
}

getStreamClient.feed(correlationType, correlationId);

await entity.get(metadata);

My metadata object has only query fields related to get information from the getStream api. I don't use the get() function to pass authentication and authorization params, this should be done at service init.
Some error stack:
"message":"{\"detail\":\"api_key is missing\",\"status_code\":401,\"code\":2,\"exception\":\"ApiKeyException\",\"duration\":\"0.00ms\"} with HTTP status code 401"
"error":{"detail":"api_key is missing","status_code":401,"code":2,"exception":"ApiKeyException","duration":"0.00ms"}

@alexabidri what is your app id?

@ferhatelmas My app id is "62246"
I will keep using the version 4 for now, I am fine with it. But hope It can help your team to find a potential issue for the new version.
Thanks :muscle:

@alexabidri Thank you for your help.
One last bit, are you sure if getStreamConfig.apiKey contains your key correctly?
I also saw some successful requests for this app with the new version. Have you made it or a colleague?

I rollbacked the v5 this morning, I was just testing for 1 hour.
Yeah, getStreamConfig.apiKey has the key correctly, when I downgrade the version without changing the code, it works back again

@alexabidri could you try to log the request and put it here
try {
  getStreamClient.on('request', console.log);
  await entity.get(metadata);
} catch (err) {
  console.log('res', err.response);
}

@mahboubii  If u dont mind, I will try tomorrow as I am on another task and I am working in Asia, already end of day 😅

@mahboubii The issue is here https://github.com/GetStream/stream-js/blob/master/src/lib/client.js#L357
this.apiKey = "API_KEY" // Api key from the stream client instance

kwargs.qs = {
  limit: 5,
  id_lt: null,
  api_key: null, // api_key is null at this moment because we dont pass it to the get() function
  withOwnReactions: true,
  withRecentReactions: true,
  withReactionCounts: true
}

const abc = {
   api_key: this.apiKey,
   location: this.group,
  ...(kwargs.qs || {}),
}

console.log(abc) => {
  api_key: null,
  location: 'unspecified',
  limit: 5,
  id_lt: null,
  withOwnReactions: true,
  withRecentReactions: true,
  withReactionCounts: true
}

The 4.5.4v is working fine https://github.com/GetStream/stream-js/blob/v4.5.4/src/lib/client.js#L493
By using the object spread operator like this, you will erase the api_key with from the client instance with null

Relevant snippet is as following,
params: {
  api_key: this.apiKey,
  location: this.group,
  ...(kwargs.qs || {}),
},

if metadata in your snippet has apiKey as null, it will override.

My bad you are right, I discussed with my frontend colleague, he was sending the api_key at some calls. This issue can be closed, sorry guys!


Set the html height outside the code snippet

I think we need to solve this. We said users need only copy paste, but this thing is not part of the copy-pasting stuff.
Originally posted by @YonatanKra in https://github.com/Vonage/vivid-3/pull/556#discussion_r926329819

we are using in several places style on the HTML for making the iftame block-size like this:
html preview


Update validations.py python script.

Fixed the behavior of validate_user function in validations.py.
Closes: #1
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[x] Tests pass
[x] Appropriate changes to README are included in PR

what is wrong?


spyder

Description
What steps will reproduce the problem?

What is the expected output? What do you see instead?
Please provide any additional information below
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\spyder\widgets\ipythonconsole\namespacebrowser.py", line 215, in _handle_execute_reply
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\spyder\widgets\ipythonconsole\namespacebrowser.py", line 215, in _handle_execute_reply
Traceback (most recent call last):
File "E:\0clue\anaconda\envs\env_gpu\lib\site-packages\qtconsole\base_frontend_mixin.py", line 138, in _dispatch
Traceback (most recent call last):
Version and main components

Spyder Version: 3.2.3
Python Version: 3.6.15
Qt Versions: 5.12.9, PyQt5 5.12.3 on Windows

Dependencies
pyflakes >=0.6.0 :  2.4.0 (OK)
pycodestyle >=2.3:  2.8.0 (OK)
pygments >=2.0   :  2.11.1 (OK)
pandas >=0.13.1  :  None (NOK)
numpy >=1.7      :  1.19.5 (OK)
sphinx >=0.6.6   :  4.3.2 (OK)
rope >=0.9.4     :  0.22.0 (OK)
jedi >=0.9.0     :  0.17.2 (OK)
nbconvert >=4.0  :  6.0.7 (OK)
sympy >=0.7.3    :  None (NOK)
cython >=0.21    :  None (NOK)
qtconsole >=4.2.0:  5.2.2 (OK)
IPython >=4.0    :  7.16.1 (OK)
pylint >=0.25    :  1.8.4 (OK)

Hey @0Louis14, thanks for reporting. This problem is caused because Spyder 3.2.3 (your current version, released more than three years) doesn't work with Qtconsole 5.2.2 (the latest one, released some weeks ago).
To solve it, you have have to remove your env_gpu environment and create a new one with the latest Spyder version available in Anaconda on it (5.1.5). Another option is to install older versions of qtconsole until you find one that works.


fix #11048 with word-break property

Fixes #11048
Please check the following:

[x] Do the tests still pass?[^1]
[x] Does the code comply with the style guide?

[x] Run make lint from the Wagtail root.

[ ] For Python changes: Have you added tests to cover the new/fixed behaviour?
[ ] For front-end changes: Did you test on all of Wagtail’s supported environments?[^2]

[x] Please list the exact browser and operating system versions you tested: Google Chrome on Windows 10
[ ] Please list which assistive technologies [^3] you tested:

[ ] For new features: Has the documentation been updated accordingly?

Please describe additional details for testing this change.
[^1]: Development Testing
[^2]: Browser and device support
[^3]: Accessibility Target
Before my fix:

After my fix:

@lb- The fix for #11048

Thanks for the before/after screenshots. This helps a lot.


NativeAdmobOptions not changing colors on app theme change

Hey,
I have a dark theme and a light theme in my app.
When initializing the app with the dark theme, all of the ads have a white text color.
When changing the theme to light, the text color of the ads remain white so its not visible (white text on white background).
Here is the code:
options: NativeAdmobOptions(
  adLabelTextStyle: NativeTextStyle(
    backgroundColor: Theme.of(context)
        .colorScheme
        .secondaryVariant,
  ),
  callToActionStyle: NativeTextStyle(
    backgroundColor: Theme.of(context).primaryColor,
    color: Colors.white,
  ),
  headlineTextStyle: NativeTextStyle(
    color:
        Theme.of(context).colorScheme.onBackground, // This is white in dark theme, and black in light theme
  ),
),

I think you should check inside the widget if any of the options are changed and rebuild the ad if it's possible.
Thanks

I had the same problem. You need to rebuild the widget manually (remove from the tree and add it again) and reload the ad

@bdlukaa Thanks for your reply,
Do you have an example of how to achieve this (removing a widget from the tree when changing a theme)?
It would be very helpful


M1 Mac directions fail

After trying to fix my installation with the following steps
brew uninstall unused
brew untap unused-code/formulae
brew tap unused-code/formulae
brew install unused --without-mimalloc

I got Error: invalid option: --without-mimalloc.
The only similar options I see are --with-mimalloc.

I assume the default has changed to support M1 Macs by default, and the only thing needed here is to update the README.

@brandondrew I just ran into this - looks like you're right: https://github.com/unused-code/homebrew-formulae/commit/a487468f4e14369311b3b464eb392c976b5f2db4 - the default is now to build it assuming it's running on Apple Silicon, with the option to build it for Intel-based Macs. So you're right that the README needs an update.

I wanted to create the same issue, got same exact problem, seems to be easy fixed.

@brandondrew @Jonic @Mayurifag anyone interested in opening a PR with your proposed changes?

@joshuaclayton Sure, I just opened a PR: #49

This has been resolved via https://github.com/unused-code/unused/pull/49


codeql: 2.5.0 -> 2.5.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/github/codeql-cli-binaries/releases.
meta.description for codeql is: "Semantic code analysis engine"
meta.homepage for codeql is: "https://semmle.com/codeql"
meta.changelog for codeql is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/3vcvfhai4hl7fa17757w41xx1k2v4dac-codeql-2.5.2/bin/codeql passed the binary check.

0 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 2.5.2 with grep in /nix/store/3vcvfhai4hl7fa17757w41xx1k2v4dac-codeql-2.5.2

found 2.5.2 in filename of file in /nix/store/3vcvfhai4hl7fa17757w41xx1k2v4dac-codeql-2.5.2

directory tree listing: https://gist.github.com/6474101e895c89708685d20bf4d064ed

du listing: https://gist.github.com/6d4e36d8bfa60cab0af31db72d83a1f2

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
0 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
0 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
codeql

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/3vcvfhai4hl7fa17757w41xx1k2v4dac-codeql-2.5.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A codeql https://github.com/r-ryantm/nixpkgs/archive/6b883c5d31fa785c15b9d62d3d30bf389f6696fe.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/3vcvfhai4hl7fa17757w41xx1k2v4dac-codeql-2.5.2
ls -la /nix/store/3vcvfhai4hl7fa17757w41xx1k2v4dac-codeql-2.5.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

codeql

Maintainer pings
cc @jollheef for testing.

Result of nixpkgs-review pr 120171 run on x86_64-linux 1

1 package built:

codeql

Result of nixpkgs-review pr 120171 at 6b883c5d run on x86_64-linux 1

1 package built successfully:

codeql

1 suggestion:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/development/tools/analysis/codeql/default.nix:42:3:
   |
42 |   installPhase = ''
   |   ^


Support moving one whole package to another

... when that package isn't necessarily defined in the same repository. Supports Java 8 to 11 migration (javax to jakarta)

Another use case is moving from shaded dependencies to regular, e.g. import shaded.<capture> to import <capture>


Tt cannot find src/main/java/caffe/Caffe.java ，where is Caffe.java？

protoc:
[exec] make[1]:  /root/CaffeOnSpark/caffe-distri'      [exec] make[1]: /root/CaffeOnSpark/caffe-distri'
[exec] make[1]: *** “src/main/java/caffe/Caffe.java”“../caffe-public/distribute/proto/caffe.proto”。
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (proto) on project caffe-distri: An Ant BuildException has occured: exec returned: 2
[ERROR] around Ant part ...... @ 5:84 in /root/CaffeOnSpark/caffe-distri/target/antrun/build-protoc.xml
[ERROR] -> [Help 1]

That's a generated file by protoc. It sounds like you had problems with protobuf.

That's my protobuf --version：
root@ubuntu001:/etc/ld.so.conf.d# protoc --version
libprotoc 2.5.0
And i think, could me use BLVC's caffe？I do this, ln -s /home/alpha/caffe caffe-public，but problm is on。

no, using BVLC caffe won't work. caffe-public is based on BVLC caffe, but with modifications.


docs(playwrighttesting): Changelog for 1.0.0-beta.5 (microsoft-playwright-testing) and 1.0.0-beta.2 (create-microsoft-playwright-testing)

Packages impacted by this PR
Issues associated with this PR
@azure/microsoft-playwright-testing
Describe the problem that is addressed by this PR
changelog
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

Informational PR naming
changed it, by mistake wrote that 🥹

API change check
API changes are not detected in this pull request.


feat: add xrsessioninit options for XRManager

Issue
#332
Details
This resolves #332

@WoodNeck
LGTM.
but add types for enterVR param.

Oops I forgot, thanks for checking


Remove PR details on squash&merge

At my company we only use the squash & merge strategy.  This is redundant, since the PR contains all commits and it is linked anyways. What we do is selecting all the text in the textarea and remove it each time we merge a PR. This is tedious and sounds like something that could be automated using refined-github.

I've got this code, which is working for me through the dev tools console, but I could use some help in creating a real extension from this:
document.querySelector(".merge-message .btn-group-squash button").addEventListener("click", function() { document.querySelector(".merge-branch-form .merge-commit-message").value = "" });

I think best would be a Cookie-backed opt-in to disable the extended commit messages on PRs for a repository.

I like this functionality as it mimics other tools for managing your workflow and code reviews. People who look at the squashed commit not on GitHub still benefit from that information.

Someone sent a similar solution (#1312) which, instead of simply clearing it, uses the first post's message.

@hkdobrev maybe I hang out in poor repos, but the commit list usually looks like this:
* Add hotkeys on Pull Request tabs

* Fix eslint errors

* Loop it up

* Further simplify selector

* Cycle through tabs

* Use .dataset

* Change hotkeys and fix broken cycle

* Add shortcut in help dialog & readme

* Fix linting

* Little fix

* Shorten readme description

* Use `g` key

Is it useful?
I'd say that if single commit information is useful, the PR should be merged with a merge commit, not squashed.


the network tunnel mode of helloworld

Hi, I tried to divert the traffic of the wg0 interface based on helloworld, but it doesn't seem to work. What is wrong?server config is as follows:
 option switch_enable '0'
 option type 'tun'
 option iface 'wg0'
 option local_port '1234'
 option alias 'WG0'
 option ip 'Usage:'

sorry, i have no idea for that.


RxNuke is not shared framework

*** Skipped building RxNuke due to the error:
Dependency "RxNuke" has no shared framework schemes

If you believe this to be an error, please file an issue with the maintainers at https://github.com/kean/RxNuke/issues/new

My bad, forgot to include a shared scheme. Fixed in https://github.com/kean/RxNuke/commit/228d4d846a029c15b0e91b0509241134f2dce98a and released https://github.com/kean/RxNuke/releases/tag/0.8.1.

Thanks! 👍


Add  pending upgrade check

This pull request is built on top of the Upgrade deliverable.
It allows checking if there is a pending upgrade, without really executing. This is useful in a CI scenario where the Umbraco upgrade will be done unattended but some actions must be done beforehand, such as displaying a static maintenance page while the upgrade is being done.

@aaronpowell the CI is failing but it seems to be related to a missing variable needed for the Code Coverage step.


Replace network parameter with indexer host in config

WHAT
Setting network name isn't enough for some indexers. For instance base has .org name instead of .io.
HOW
Use indexer host as parameter to make diffyscan more flexible.

@mymphe @kovalgek maybe we should have two parameters?
network and etherscan_host?


isless for complex coefficient in autompo, with test

The coef of each MPOterm is complex, but before this commit, line 61 was
coef(t1) < coef(t2)
So if execution ever reached this line (which it did not in any of the tests, AFAICT), this line would fail: there is no method isless for those Complex{Float64} variables.
This commit replaces that line with a check for a "lexicographic ordering", and adds a test that should trigger the bug in the old code.
Incidentally, none of this code will check for or gracefully handle terms with coef NaN.

Should've mentioned: this is all in autompo.jl

Codecov Report

Merging #134 into master will decrease coverage by 0.13%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #134      +/-   ##
==========================================
- Coverage   88.67%   88.54%   -0.14%
==========================================
  Files          32       32
  Lines        2852     2854       +2
==========================================
- Hits         2529     2527       -2
- Misses        323      327       +4

Impacted Files
Coverage Δ

src/physics/autompo.jl
92.02% <100%> (-2.07%)
:arrow_down:

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 22a6d48...d2f1d7a. Read the comment docs.

Hi Christopher, did you mean to include the commits with real_if_close and other changes into this pull request? Is that feature related to the isless and AutoMPO fix? Thanks -

Nope. Those are for the next pull request (at the moment sample can't handle complex MPSs, so I went and fixed that.)
I knew if I couldn't have two open at the same time, but I didn't realize that GitHub would automatically add the new stuff to the old pull request. Sorry about that

Did a reset and push --force. Should be down to only that one commit now.

Thanks for this Christopher. Good catch. I will make a small change to the unit test after pulling to make it more robust to internal changes to AutoMPO, but appreciate the PR and the test.


closes #34   add footer

closes #34

@Sejal-16 Can you please attach a screenshot.

https://user-images.githubusercontent.com/58871818/135760359-9a059f36-f874-44ad-8654-2695f21cbf0f.mp4
The footer should not be stickey like this it.

But there are conflicts , will you be merging it ?

Conflicts resolved.


(PUP-5341) Emit TagSets as arrays in report YAML

Resource::Status and Util::Log objects were not including PsychSupport
to allow them to serialize their tags member as an array.

I'm not sure what the best way to test this is - do we have an actual schema for reports that I could try to make stricter or something like that?

I don't think we have a schema. But that would be great :)
What we have in facter, where there's a schema and then an acceptance test that generates output to validate against that schema, might be the basis for such a test. Otoh, it might be riggable as a spec/integration test, which would be nice for faster feedback loop.

There are other tests in puppet that do stuff with schemas - I think we used it to validate that the schemas we wrote were valid.

+1 to the fix, including PsychSupport was the right thing to do

This is updated with a test now (woohoo). Maybe could be unit instead of integration? It's definitely hitting a pretty wide swath of the codebase so doesn't feel "unit-y" to me, but also it doesn't interact with the underlying system. I'm not sure how the tests are suposed to be split up in Puppet core.
We need to wait for the 4.4.0 tag before we merge this, since it's targeted for 4.4.1

Needs a rebase.

@MikaelSmith rebase done, tests are running


feat: Add ActiveJob instrumentation

This is a slightly modified version of the ActiveJob instrumentation
that we have been running for a few weeks now, on two different internal
applications. It is somewhat basic, but it works well enough.
There are a few things of note:

We track a few custom attributes for ActiveJob - I'm not sure if the
naming is good, however.
~We do not attempt to pass any kind of context propagation through the
job system. I have successfully done that via job-argument-mangling,
but didn't do so here. We've found that doing so leads to unwieldy
traces for web requests that enqueue background jobs.~ edit: now we do, if you pass the context_propagation: :child argument. otherwise we use span links by default.
I've tried to follow the overall messaging semantic conventions, since
'job' semantic conventions have not materialized yet. I'll update this
PR if they are finalized before this is merged; otherwise we can make
those updates later.
The test suite is a tad slow - to test a few features, I needed to
explicitly use a real job system - in this case, the async adapter.
It's all still in-process, but uses threads as a queueing system. I
found the easiest thing to do was to just call sleep in a few places.

Probably the most important things to think about when reviewing are:

Are the attributes added correct (or - are they at least close to
correct until we have proper job semantic conventions)?
~Following a job produce -> job enqueue requires searching your tracing
system on the value of messaging.message_id. Is that ergonomic or
should we do something different?~ edit: span links are set by default, and users can opt-in to parent/child context semantics.

I'd appreciate anyone who's willing to test this out in a production
system - I think. We're going to test this version internally as well,
since it differs in a few small ways from what we actually run today.

Example span (async adapter)
❯ bundle exec ruby ./active_job.rb
I, [2021-04-23T15:45:02.363340 #43810]  INFO -- : Instrumentation: OpenTelemetry::Instrumentation::ActiveJob was successfully installed
#<struct OpenTelemetry::SDK::Trace::SpanData[ActiveJob] [TestJob] [ac093fd0-1221-4027-83f3-042643f7622b] Performing TestJob (Job ID: ac093fd0-1221-4027-83f3-042643f7622b) from Async(default) enqueued at 2021-04-23T20:45:02Z

 name="TestJob send",
 kind=:producer,
 status=
  #<OpenTelemetry::Trace::Status:0x00007fb35bc4a728 @code=1, @description="">,
 parent_span_id="\x00\x00\x00\x00\x00\x00\x00\x00",
 total_recorded_attributes=5,
 total_recorded_events=0,
 total_recorded_links=0,
 start_timestamp=2021-04-23 15:45:02.364016 -0500,
 end_timestamp=2021-04-23 15:45:02.364252 -0500,
 attributes=
  {"messaging.destination_kind"=>"queue",
   "messaging.system"=>"async",
   "messaging.destination"=>"default",
   "messaging.message_id"=>"ac093fd0-1221-4027-83f3-042643f7622b",
   "net.transport"=>"inproc"},
 links=nil,
 events=nil,
 resource=
  #<OpenTelemetry::SDK::Resources::Resource:0x00007fb35b9f2c00
   @attributes=
    {"service.name"=>"unknown_service",
     "process.pid"=>43810,
     "process.command"=>"./active_job.rb",
     "process.runtime.name"=>"ruby",
     "process.runtime.version"=>"2.7.2",
     "process.runtime.description"=>
      "ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin19]",
     "telemetry.sdk.name"=>"opentelemetry",
     "telemetry.sdk.language"=>"ruby",
     "telemetry.sdk.version"=>"0.17.0"}>,
 instrumentation_library=
  #<struct OpenTelemetry::SDK::InstrumentationLibrary
   name="OpenTelemetry::Instrumentation::ActiveJob",
   version="0.17.0">,
 span_id="\xAB\tY6\x04\x95r\xA1",
 trace_id="]W\x05\xD9UV`\xB3N\x93\xAF\xAAin~S",
 trace_flags=#<OpenTelemetry::Trace::TraceFlags:0x00007fb33b83e7f8 @flags=1>,
 tracestate=#<OpenTelemetry::Trace::Tracestate:0x00007fb35bbaa4d0 @hash={}>>
[ActiveJob] Enqueued TestJob (Job ID: ac093fd0-1221-4027-83f3-042643f7622b) to Async(default)

--------------------------------------------------
 The computer is doing some work, beep beep boop.
--------------------------------------------------

#<struct OpenTelemetry::SDK::Trace::SpanData
 name="TestJob process",
 kind=:consumer,
 status=
  #<OpenTelemetry::Trace::Status:0x00007fb35bc4a728 @code=1, @description="">,
 parent_span_id="\x00\x00\x00\x00\x00\x00\x00\x00",
 total_recorded_attributes=7,
 total_recorded_events=0,
 total_recorded_links=0,
 start_timestamp=2021-04-23 15:45:02.44189 -0500,
 end_timestamp=2021-04-23 15:45:02.441939 -0500,
 attributes=
  {"messaging.destination_kind"=>"queue",
   "messaging.system"=>"async",
   "messaging.destination"=>"default",
   "messaging.message_id"=>"ac093fd0-1221-4027-83f3-042643f7622b",
   "net.transport"=>"inproc",
   "messaging.operation"=>"process",
   "messaging.active_job.executions"=>1},
 links=nil,
 events=nil,
 resource=
  #<OpenTelemetry::SDK::Resources::Resource:0x00007fb35b9f2c00
   @attributes=
    {"service.name"=>"unknown_service",
     "process.pid"=>43810,
     "process.command"=>"./active_job.rb",
     "process.runtime.name"=>"ruby",
     "process.runtime.version"=>"2.7.2",
     "process.runtime.description"=>
      "ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin19]",
     "telemetry.sdk.name"=>"opentelemetry",
     "telemetry.sdk.language"=>"ruby",
     "telemetry.sdk.version"=>"0.17.0"}>,
 instrumentation_library=
  #<struct OpenTelemetry::SDK::InstrumentationLibrary
   name="OpenTelemetry::Instrumentation::ActiveJob",
   version="0.17.0">,
 span_id="\x9B:\x8A\xCC`\x91H\xED",
 trace_id="X\xE7\xE0\xCA\xA6\xA8\x1EG\x80J\x98\x91<!f\xAD",
 trace_flags=#<OpenTelemetry::Trace::TraceFlags:0x00007fb33b83e7f8 @flags=1>,
 tracestate=#<OpenTelemetry::Trace::Tracestate:0x00007fb35bbaa4d0 @hash={}>>
[ActiveJob] [TestJob] [ac093fd0-1221-4027-83f3-042643f7622b] Performed TestJob (Job ID: ac093fd0-1221-4027-83f3-042643f7622b) from Async(default) in 79.23ms

cc #222

@ahayworth ahh just saw this was in draft mode. Sorry for the premature feedback.

@ahayworth ahh just saw this was in draft mode. Sorry for the premature feedback.

That's alright; I accidentally re-requested reviews when I tried to update my branch and committed a git foot-gun. 😄

A few general things:

I think we should try to propagate context, including baggage. Not doing that is quite limiting (e.g. for analysis involving both the enqueuing process and the job execution), unless ...
If ActiveJob has some kind of job ID, it could be used as a correlation ID, which would enable many analyses on some backends. Baggage has other benefits, though, as does trace context (e.g. for consistent sampling).
We should add a configuration option (to all job-system instrumentation, consistently named) to toggle between linking traces and continuing traces. I would tend to default to starting a new trace for the job execution with a link back to the trace for the enqueuing process. Links are not necessarily well supported by all trace backends, but they're part of the spec and should become more widely supported 🔜

Thanks for the feedback @fbogsany - I got 3/4 of the way through re-implementing it (and incidentally, doing what you suggested) but got distracted. This is a good reminder for me to finish. 😆

We should add a configuration option (to all job-system instrumentation, consistently named) to toggle between linking traces and continuing traces.

Do you have a feeling on what that name should be? And more specifically, is this something that should be supported per-job, or for all jobs traced via a given instrumentation library? The PR as it stands (which works, but tests are not fixed yet) allows for per-job configuration, but that may not be the right approach.

Do you have a feeling on what that name should be?

I like my bike sheds yellow 😄. I don't have a strong opinion, or I won't until someone expresses one I don't like :trollface:.

And more specifically, is this something that should be supported per-job, or for all jobs traced via a given instrumentation library? The PR as it stands (which works, but tests are not fixed yet) allows for per-job configuration, but that may not be the right approach.

At least a global option should be provided. I can sort of see the value of per-job configuration, but I am unlikely to reach for it.

@open-telemetry/ruby-approvers this is ready for review (I noticed a redis test failure, but all activejob tests are passing). I believe I have a reasonable solution to serializing context along with the job, by re-using the built-in argument serializing capabilities of ActiveJob. Unless I've misunderstood things (and I may have), I believe this gets baggage too @fbogsany - please let me know if that's not the case.
I chose a global option for how to configure propagation, and it defaults to actually just linking to the enqueueing trace rather than setting up a parent/child relationship. One weird note is that the :inline queue adapter renders the context propagation moot; and the job execution is always in the same trace where it was enqueued. That's because ActiveJob executes the job while in the process of enqueueing it when using the :inline adapter; and honestly I didn't feel like jumping through a ton of hoops to detect that case and do something about it. In any case, if you're using the :inline adapter then I can't imagine why you wouldn't want your job's execution to be in the same logical trace, anyways.
I've been testing an older version of this internally, and it seemed okay - but I'll deploy this to production and make sure nothing unexpected blows up - but I think it's ready now!

I'm not certain if the span names I've chosen actually follow the messaging semantic attributes: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md#span-name
I think having the job class as part of the span name makes it a lot more useful, since there's no other way in the semantic conventions to define the job name; and the background-job semantic conventions PR has not yet been approved. I'm curious what people think we should do:

We could keep what we have. In backend systems that display the span name, this works nicely (it's not so helpful in other systems...)
We could adhere more closely to the messaging conventions and add the class name as something like active_job.job: FooJob in the span attributes, which may be the "best of both worlds approach"
We could venture out on a limb and apply the not-yet-merged Job semantics, if we think they're likely to be accepted.

Curious what others think here.

In the Sidekiq instrumentation, we added an option to use the job class name as the span name: https://github.com/open-telemetry/opentelemetry-ruby/blob/bda1fb057c63f174c81c687631a35559362c7e26/instrumentation/sidekiq/lib/opentelemetry/instrumentation/sidekiq/instrumentation.rb#L30
I think that's a reasonable compromise.

@fbogsany I agree, and added that option in 0cfe562. I'm fighting with the test suite (yay) and the cop (yay) but I think the PR is otherwise in a decent state.

Fun:
opentelemetry-instrumentation-active_job: test
C:/hostedtoolcache/windows/Ruby/3.0.1/x64/lib/ruby/3.0.0/logger/log_device.rb:103:in `initialize': No such file or directory @ rb_sysopen - /dev/null (Errno::ENOENT)

Note that after #820 was merged, in 982e7a6 we now need to call OpenTelemetry.tracer_provider.force_flush, rather than ActiveJob::Instrumentation.instance.tracer.tracer_provider.force_flush. I think that's still safe, but I'm not sure.


NVM Issue on running first step of installation: curl command

Operating system and version: osX v10.11

Stuck in Install on this stage:
nvm_do_install() {
if [ -n "${NVM_DIR-}" ] && ! [ -d "${NVM_DIR}" ]; then
echo >&2 "You have $NVM_DIR set to "${NVM_DIR}", but that directory does not exist. Check your profile files and environment."
exit 1

Stuck on this stage: curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash with error above

Solved it by re-opening terminal. But still curious as to why this occurred as I am still in the same user as where I ran command

@WizardOfAus would you please fill out the entire issue template, omitting nothing?

I get the same thing on Ubuntu when I change to another user then try to install NVM which never used to happen. export NVM_DIR="$INSTALL_DIR" Fixed it for me.

If you change to another user in a way that preserves the environment variables from the old user, then that's expected.
I'm going to close this since there's not enough info in the OP.

I get the same thing on Ubuntu when I change to another user then try to install NVM which didn't happen to me in the past. export NVM_DIR="$INSTALL_DIR" Fixed it for me.

Great！


Add a tool to set the wifi configuration of the inverter

Should be a matter of retrieving a GetConfig response, encode the changed information and play it back in a SetConfig request

Since I want to run my inverter in a network without internet access and would also prefer to get it there without downloading any apps or register an account, it would be very helpful to have this tool available. Let me know if I can help test with my inverters

That's a very good reason to have this feature. Implementing this will likely start early next year.

I did a quick test last year and I can connect to the inverter just fine. I used the following script to read the config: https://github.com/henkwiedig/Hoymiles-DTU-Proto/blob/main/GetConfig.py
Don't have the config with me, but I'll upload it tonight. Maybe someone with an already provisioned inverter could paste their config here (with obfuscated passwords, wifi names,  and serial numbers of course). Just let me know if the wifi password is somehow encoded or just plain text like the default password.
Then I'll diff it and would try to send it to one of my inverters for testing.

These are the fields I get from the above GetConfig run:
time: 12627 netmode_select: 1 server_send_time: 15 serverport: 10081 meter_kind: 2.1.21_hm meter_interface: 2.1.21_hm wifi_ssid: DTU-W600 wifi_passward: 12345678 server_domain_name: dataeu.hoymiles.com dtu_sn:<PHONE_NUMBER>11 access_model: 1 cable_dns_0: 223 cable_dns_1: 6 cable_dns_2: 6 cable_dns_3: 6 wifi_mac_0: 11 wifi_mac_1: 111 wifi_mac_2: 111 wifi_mac_3: 11 wifi_mac_4: 111 wifi_mac_5: 11 dtu_ap_ssid: DTUBI-11111111 dtu_ap_pass: xxxxxxxx
The following fields were obfuscated: dtu_sn, wifi_mac_x, dtu_ap_ssid and dtu_ap_pass
Could someone with a inverter connected to a wifi run the GetConfig script and post the values here please? With obfuscation of the mentioned fields plus wifi_ssid and wifi_passward.
That would be very helpful!

Cool! I'll see if I can get it to run end of week.

It's all there in clear text:
offset: 3600
time:<PHONE_NUMBER>
netmode_select: 1
server_send_time: 15
wifi_rssi: 70
serverport: 10081
meter_kind: 2.1.21_hm
meter_interface: 2.1.21_hm
wifi_ssid: <redacted cleartext>
wifi_passward: <redacted cleartext>
server_domain_name: dataeu.hoymiles.com
dtu_sn: <redacted sn>
access_model: 1
cable_dns_0: 223
cable_dns_1: 5
cable_dns_2: 5
cable_dns_3: 5
wifi_ip_addr_0: 192
wifi_ip_addr_1: 168
wifi_ip_addr_2: 4
wifi_ip_addr_3: 182
wifi_mac_0: <redacted cleartext>
wifi_mac_1: <redacted cleartext>
wifi_mac_2: <redacted cleartext>
wifi_mac_3: <redacted cleartext>
wifi_mac_4: <redacted cleartext>
wifi_mac_5: <redacted cleartext>
dtu_ap_ssid: <redacted cleartext>
dtu_ap_pass: <redacted cleartext>

I have looked further into this issue and it seems this is pretty easy to achieve, i.e. will be adding a tool that is just setting wifi SSID and password, and dns servers.

I was actually also wondering whether I need to send the whole config
back (like in the SetConfig example in the other repo) or I could just
send some of the values.
I could try to just set the wifi AP settings tomorrow. I'll let you know
what happens ;)

@DennisOSRM
I have implemented this functionality in:
https://github.com/suaveolent/hoymiles-wifi
if you need any help with it.
Trying to send the wifi configuration only did, however, not work in my attempts. The only solutions seems to be to send the entire config back. The sMiles installer application also does this the same way.

@DennisOSRM
I have implemented this functionality in:
https://github.com/suaveolent/hoymiles-wifi
if you need any help with it.
Trying to send the wifi configuration only did, however, not work in my attempts. The only solutions seems to be to send the entire config back. The sMiles installer application also does this the same way.

Cool. Thanks so much for sharing. This is super helpful.

I tried setting the wifi with the hoymiles-wifi script by @suaveolent and
can confirm that it works with an inverter straight out of the box! I
have some connection problems, but that might be a local problem and I
have to debug further.
Can't reach the inverter when it is in the target wifi and it seems to
drop the connection frequently. Might be because of wifi strength or
because it can't reach the internet through that wifi.
I'll report back soonish

I tried setting the wifi with the hoymiles-wifi script by @suaveolent and can confirm that it works with an inverter straight out of the box! I have some connection problems, but that might be a local problem and I have to debug further. Can't reach the inverter when it is in the target wifi and it seems to drop the connection frequently. Might be because of wifi strength or because it can't reach the internet through that wifi. I'll report back soonish

Thanks for letting me know. Might also be due to an old firmware.
I will look into how firmware updates are supplied and maybe add the functionally to the library.

@suaveolent Maybe have a look here: https://github.com/veganmosfet/Balcony_in_the_cloud#firmware-update
@veganmosfet might be able to help. He triggered it through the cloud connection though, but there possibly is a more direct way to trigger the firmware download/update.
It won't be as straight forward as setting the wifi info though, cause it likely involves some DNS bending and supplying the firmware image locally (see Post-patch reproduction in the above repo)
I also though about just changing the server_domain_name config property and point it back to the IP/host where the script is running. You could open a webserver, accept the connection from the DTU and request it to download a firmware update.

I don't know for the HMS devices but for the HM device you can just send an update command locally from a PC to the DTU and then the DTU will fetch the firmware.
I involved the cloud, so only part of the url was under control. However, the command from the cloud to the DTU includes the full url, so no need to mess up with dns.
My proposal: you trigger an update from the cloud and at the same time record the Ethernet traffic of your inverter. Then you can extract the local "update" command, the full url is included in plaintext there in the TCP packet content.

I don't know for the HMS devices but for the HM device you can just send an update command locally from a PC to the DTU and then the DTU will fetch the firmware. I involved the cloud, so only part of the url was under control. However, the command from the cloud to the DTU includes the full url, so no need to mess up with dns. My proposal: you trigger an update from the cloud and at the same time record the Ethernet traffic of your inverter. Then you can extract the local "update" command, the full url is included in plaintext there in the TCP packet content.

Sounds like a good idea. Will try to capture the relevant packages.
I will also try to capture the relevant packages to set the grid profile.

Making some progress:
The firmware is loaded from:
http://fwupdate.hoymiles.com/cfs/bin/2311/06/1488725943932555264.bin

@dicer I have released a new version (v.0.0.8) which should implement the firmware upgrade, if you feel lucky.
I cannot confirm if it works, since I have already installed the V00.01.11 before.
However, when issuing the command, the inverter goes offline for a couple of minutes and then resumes operation.
I will monitor the network in the future, to see if it really executes the command.

@dicer After inspecting the network traffic I can confirm: after issuing the firmware update the inverter downloads the firmware from the hoymiles server.
This means we probably can also host the firmware somewhere else.

I moved the discussion about updating the firmware over to https://github.com/suaveolent/hoymiles-wifi/pull/1
No need to spam this issue any more, which is about setting the wifi config (which works for me, but the inverter keeps dropping from the wifi very regularly).
But maybe someone is able/willing to try connecting their unregistered(!) inverter to the internet (with the tool by @suaveolent)  and see if the inverter behaves the same if the cloud is reachable. I'm running the inverter in a wifi with no internet connection and am still unsure if the wifi dropping is related to not being able to connect to the internet at all, not being registered with the cloud, the old firmware or some local problem.

I would assume the wifi issue to be unrelated to cloud connectivity. My inverter is isolated from the internet, i.e. all outgoing packages from it are dropped at the gateway and the connection to the wifi is pretty solid.

I see exactly 94 pings to the inverter succeed, then around 230-250 pings fail and then it comes back for exactly 94 pings again and so on. So for me it pretty solidly fails ;)

I see exactly 94 pings to the inverter succeed, then around 230-250 pings fail and then it comes back for exactly 94 pings again and so on. So for me it pretty solidly fails ;)

Same issue with me. The HMS-800W-2T establishes connection every 15 minutes for a few seconds and drops its data to the cloud. The other time the WiFi seems of.