Added Sign Data Endpoint (via new AuthHandler)

New AuthHandler route providing getSignData function accessible via the new /api/sign_data/:msg endpoint, which simply links to the blockchain's .../sign_data/{msg} endpoint.
General refactoring and cleanup.

Closed in favor of more accurately PR (more accurate branch name) #32


Fix SIMPLE Authentication scheme

Let's adjust the ILP-over-HTTP SIMPLE auth scheme to better support the RFC and Rust implementation.
The new SIMPLE scheme for the Java Connector is: {account_id}:{shared_secret}
#TASKS

Accounts API

Don’t allow a colon in the account_id
shared_secret must be ASCII
account_id must be ASCII

Remove ilpOverHttp.incoming.token_subject from custom settings for SIMPLE profile (this value is encoded into the shared_secret in this profile)
Remove all Base64-encoding from the SIMPLE scheme

See the Connector's implementation of BearerTokenSupplier
See DefaultLinkSettingsValidator - stop Base64-decoding and use raw input text.
In IlpOverHttpAuthenticationProvider -  stop Base64-decoding the token portion of the incoming bearer token.

This issue has been superseded by https://github.com/sappenin/java-ilpv4-connector/issues/405


Fix shallowEqual hasOwnProperty check, issue #233

Fixes the issue explained in #233, copying my explanation from that issue:
Since you don't check hasOwnProperty on b, only on a, the prototype methods __ARRAY__ and equals are checked and the !a.hasOwnProperty(key) always returns true.

Sorry I am not following the problem,
https://codepen.io/anon/pen/dVbGxE?editors=0012
the old version seems to return true when comparing arrays

Not sure why it doesn't happen in your example, but when I'm using your library I get results like this when ChartCanvas tries to compare this.props.xExtents and nextProps.xExtents with shallowEqual:

The for (key in b) loop in my case (but not in your example) iterates over the two prototype methods equal and __ARRAY__, so even though the dates are the same the test returns false because !a.hasOwnProperty(key) is true for those two keys.


Missing languages

pt-br and a couple langs are unavailable for me on v0.9.4.

Hey @kaioduarte, at the new version localization dependent on date-fns's locales and we dropped support for this version. The new version could be a solution for you. If not you can open an issue at date-fns repo for locale support request.


How to update translations?

What's the correct way to update translations and customise the appearance? It seems whenever I install the plugins everything is getting overwritten

You can customize the translations if you build from source. You will need to edit the files under src/app/translation, before the npm run build step.

This translation doesn't seem to be available, does src/app/translation overwrite the component translations?
Ethereum Lite Explorer
An open source Ethereum block explorer. Available on GitHub

I see the problem. There is no easy way of changing those texts. As they are defined in one of the core plugins, you don't have direct access to them. So, until we make a proper fix, there are some things you could do right now:
The easy and ugly fix: directly editing the generated files under dist/plugins/aleth.io/eth-common/js. You'll have to manually find the bundle that contains the translations and change them in place. :(
There's also a slightly cleaner solution, but it's rather tedious for a simple text change. You could create a plugin that reimplements the page://aleth.io/dashboard object. You can start by reading the tutorial in the Alethio/cms repo readme. and then you could create a plugin that exports the new implementation of that object. You replace the page in the explorer's config with your own. I can provide more detailed steps if you want to go this way.
On the long run, we should also fix this properly on our side. We have a few possible options:
a. Have a way of overriding specific plugin translations from the main app translation files. This would still require forking the project and rebuilding. Not ideal
b. Load the translations at runtime from JSONs instead of relying on Webpack, so that we can mount a custom file instead / overwrite the files. This would allow overriding specific translations without having to rebuild anything and it would work in both Docker-based and build-from-source setups. This would however mean that we treat the translations as data files and so we'd need a versioning scheme for them.
c. (specific fix) Just move the title and subtitle into a separate module instead of hardcoding them in the page object. This way we can override the texts by replacing the module with a custom implementation, instead of cloning the whole page layout.

Fixed. See https://github.com/Alethio/ethereum-lite-explorer#override-specific-text-strings-translations for instructions.
As per linked PR, option c) from above post was implemented.

Also make sure to npm install after git pull. Some dependencies were updated.


Replace sexe with shexe or something else

I think sexe is an abbreviation for shell execute. It can read like "sexy", and we can probably pick a better name. Mark has proposed shexe.
FWIW, be aware that this instance is one of about 25 in our code base.
Originally posted by @markcmiller86 in https://github.com/visit-dav/visit/pull/5725#discussion_r638427293

It might be that sexe is an exported symbol that other users can use. We might want to leave the old spelling for a release with a deprecation notice and call foward shexe

Hi @rusu24edward @markcmiller86 , is the issue resolved ?
Or can I do it ?

Adding a test message to see what happens if I fully delete it

I guess change is merged so if there is nothing too work on this issue may be closing this issue will be better :smile:

@itsSanto I do not believe this ticket is resolved. You may be referring to the link "Originally posted by ..." in the description box above. This is not a change that fixes this issue; it is only a reference to the changes that first made us aware of the issue.


[tool_crash] RPCError

Command
flutter run

Steps to Reproduce

...
...
...

Logs
RPCError

[✓] Flutter (Channel beta, 2.0.1, on macOS 11.2.3 20D91 darwin-x64, locale en-IN)
    • Flutter version 2.0.1
    • Framework revision c5a4b4029c (12 days ago), 2021-03-04 09:47:48 -0800
    • Engine revision 40441def69
    • Dart version 2.12.0

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK
    • Platform android-30, build-tools 30.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.4, Build version 12D4e
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 48.0.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.54.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.20.0

[✓] Connected device (3 available)
    • iPhone (mobile) • 00008030-0009490E01D2802E • ios            • iOS 14.4.1
    • macOS (desktop)          • macos                     • darwin-x64     • macOS 11.2.3 20D91 darwin-x64
    • Chrome (web)             • chrome                    • web-javascript • Google Chrome 89.0.4389.82
    ! Error: iPhone is busy: Copying cache files from device. Xcode will continue when  iPhone is finished. (code -10)

• No issues found!

Flutter Application Metadata
Type: app
Version: 1.0.0+1
Material: true
Android X: false
Module: false
Plugin: false
Android package: null
iOS bundle identifier: null
Creation channel: stable
Creation framework version: e6b34c2b5c96bb95325269a29a84e83ed8909b5f
Plugins
firebase_core-0.5.0
firebase_core_web-0.2.0
firebase_messaging-7.0.0
path_provider-1.6.8
path_provider_macos-0.0.4+2
sqflite-1.3.0+1
url_launcher-5.4.10
url_launcher_macos-0.0.1+7
url_launcher_web-0.1.1+6
video_player-0.10.11+2
video_player_web-0.1.3+1
wakelock-0.1.4+1
whatsapp_stickers-0.0.4

possible duplicate of https://github.com/flutter/flutter/issues/78099

Closing as duplicate of https://github.com/flutter/flutter/issues/78099.


chore(ci): ensure ad-hoc apt doesnt time out

We should configure apt to be lenient here

Docs Preview
Hey there! 👋 You can check your preview at https://6657baefbe0c9e5f9a3b83b4--aztec-docs-dev.netlify.app

Benchmark results
Metrics with a significant change:

proof_construction_time_poseidon_hash_100_ms (1): 4,615 (-20%)
proof_construction_time_poseidon_hash_30_ms (1): 1,235 (-19%)
proof_construction_time_sha256_ms (1): 4,606 (-20%)
proof_construction_time_sha256_100_ms (1): 35,671 (-19%)
proof_construction_time_sha256_100_ms (4): 9,728 (-17%)
proof_construction_time_sha256_100_ms (16): 4,407 (-19%)
proof_construction_time_sha256_100_ms (32): 4,474 (-18%)
proof_construction_time_sha256_100_ms (64): 4,436 (-17%)
proof_construction_time_sha256_30_ms (1): 9,179 (-23%)
proof_construction_time_sha256_30_ms (4): 2,581 (-20%)
proof_construction_time_sha256_30_ms (16): 1,159 (-18%)
proof_construction_time_sha256_30_ms (64): 1,219 (-17%)
app_circuit_witness_generation_time_in_ms (ContractClassRegisterer:register): 353 (-25%)
app_circuit_witness_generation_time_in_ms (MultiCallEntrypoint:entrypoint): 1,435 (-16%)
app_circuit_witness_generation_time_in_ms (Token:privately_mint_private_note): 1,312 (-20%)
app_circuit_witness_generation_time_in_ms (Token:transfer): 4,022 (-20%)
app_circuit_witness_generation_time_in_ms (Token:unshield): 3,081 (-17%)
app_circuit_witness_generation_time_in_ms (FPC:fee_entrypoint_private): 3,779 (-17%)
protocol_circuit_simulation_time_in_ms (private-kernel-inner): 328 (-20%)
protocol_circuit_simulation_time_in_ms (private-kernel-tail): 451 (-23%)
protocol_circuit_simulation_time_in_ms (base-rollup): 551 (-27%)
protocol_circuit_simulation_time_in_ms (public-kernel-app-logic): 417 (-23%)
protocol_circuit_simulation_time_in_ms (public-kernel-tail): 869 (-23%)
protocol_circuit_simulation_time_in_ms (private-kernel-reset-small): 470 (-21%)
protocol_circuit_simulation_time_in_ms (public-kernel-setup): 464 (-28%)
protocol_circuit_simulation_time_in_ms (public-kernel-teardown): 393 (-27%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-init): 344 (-31%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-reset-small): 1,571 (-25%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-tail-to-public): 5,916 (-32%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-inner): 693 (-31%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-tail): 2,008 (-29%)
protocol_circuit_witness_generation_time_in_ms (base-parity): 938 (-22%)
protocol_circuit_witness_generation_time_in_ms (base-rollup): 1,932 (-16%)
protocol_circuit_witness_generation_time_in_ms (public-kernel-app-logic): 2,593 (-18%)
protocol_circuit_proving_time_in_ms (private-kernel-init): 10,437 (-21%)
protocol_circuit_proving_time_in_ms (base-parity): 2,349 (-19%)
l2_block_building_time_in_ms (8): 37,867 (-18%)
l2_block_building_time_in_ms (32): 153,589 (-17%)
l2_block_building_time_in_ms (64): 301,538 (-18%)
l2_block_rollup_simulation_time_in_ms (8): 37,714 (-18%)
l2_block_rollup_simulation_time_in_ms (32): 153,004 (-17%)
l2_block_rollup_simulation_time_in_ms (64): 300,427 (-18%)
l2_block_public_tx_process_time_in_ms (8): 19,793 (-20%)
l2_block_public_tx_process_time_in_ms (32): 86,982 (-16%)
l2_block_public_tx_process_time_in_ms (64): 174,352 (-18%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
:warning: 4,606 (-20%)
1,318 (-15%)
612 (-12%)
662 (-13%)
662 (-15%)

proof_construction_time_sha256_30_ms
:warning: 9,179 (-23%)
:warning: 2,581 (-20%)
:warning: 1,159 (-18%)
1,227 (-14%)
:warning: 1,219 (-17%)

proof_construction_time_sha256_100_ms
:warning: 35,671 (-19%)
:warning: 9,728 (-17%)
:warning: 4,407 (-19%)
:warning: 4,474 (-18%)
:warning: 4,436 (-17%)

proof_construction_time_poseidon_hash_ms
64.0 (-18%)
30.0 (-12%)
29.0 (-15%)
48.0 (-17%)
73.0 (-16%)

proof_construction_time_poseidon_hash_30_ms
:warning: 1,235 (-19%)
370 (-11%)
183 (-10%)
225 (-2%)
241 (-9%)

proof_construction_time_poseidon_hash_100_ms
:warning: 4,615 (-20%)
1,351 (-14%)
617 (-15%)
662 (-15%)
674 (-15%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,464
9,452
9,464

l1_rollup_execution_gas
616,105
616,093
616,105

l2_block_processing_time_in_ms
1,362 (+6%)
5,194 (+9%)
9,991 (+5%)

l2_block_building_time_in_ms
:warning: 37,867 (-18%)
:warning: 153,589 (-17%)
:warning: 301,538 (-18%)

l2_block_rollup_simulation_time_in_ms
:warning: 37,714 (-18%)
:warning: 153,004 (-17%)
:warning: 300,427 (-18%)

l2_block_public_tx_process_time_in_ms
:warning: 19,793 (-20%)
:warning: 86,982 (-16%)
:warning: 174,352 (-18%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
9,400 (-1%)
14,405

node_database_size_in_bytes
14,508,112
21,373,008

pxe_database_size_in_bytes
18,071
29,868

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.5
17.1
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.7
31.8
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.611
0.526 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
49.1 (+1%)
79.1 (+3%)
263 (+7%)
473
1,011 (+9%)
1,924 (+5%)
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.504 (+2%)
0.489 (+3%)
0.478 (+7%)
0.442
0.480 (+9%)
0.459 (+5%)
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
58.6 (+1%)
117 (+4%)
371 (+5%)
695 (-1%)
1,503 (+9%)
2,904 (+6%)
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
106
208
692
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.511 (+2%)
0.525 (+4%)
0.505 (+5%)
0.479
0.520 (+9%)
0.506 (+6%)
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
64.1 (+2%)

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
107

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.571 (+3%)

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
84,050
665,267

Transaction size based on fee payment method
| Metric |  |
| - |  |


Cannot register if order is made as guest

medusa-plugin-auth
I'm receiving Internal Server Error if I'm trying to register after I have made an order without registration
Error: Guest customer with email already exists
at CustomerService.<anonymous> (/app/node_modules/@medusajs/medusa/dist/services/customer.js:419:55)
at step (/app/node_modules/@medusajs/medusa/dist/services/customer.js:59:23)
at Object.next (/app/node_modules/@medusajs/medusa/dist/services/customer.js:40:53)
at fulfilled (/app/node_modules/@medusajs/medusa/dist/services/customer.js:31:58)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
```

The current behaviour is that if no validated account exists then we try to create the customer, maybe we can change that to just check if any accounts exists with the email?

I think this error is because password field is missing. When I try to register using signup form it works.
https://github.com/medusajs/medusa/blob/develop/packages/medusa/src/services/customer.ts#L328

I will be 3 weeks away and tried to relax a bot, maybe if you could ipen a pr if you feel something can be done as a proposal so i can look at it when i am free, would you be keen to do that @FaZeRs ? 😍

@adrien2p as I see alternative would be to create method in auth plugin which does the input data validation and creates customer using CustomerRepository. Maybe you have got any other ideas?

Did you find a solution for your case?


add Id as base type of vertex id

Codecov Report

Merging #4 (c96ce65) into master (7675d96) will increase coverage by 43.92%.
The diff coverage is 83.01%.

@@              Coverage Diff              @@
##             master       #4       +/-   ##
=============================================
+ Coverage     26.66%   70.58%   +43.92%
- Complexity        6       84       +78
=============================================
  Files             5       14        +9
  Lines            45      204      +159
  Branches          1       12       +11
=============================================
+ Hits             12      144      +132
- Misses           33       51       +18
- Partials          0        9        +9

Impacted Files
Coverage Δ
Complexity Δ

.../baidu/hugegraph/computer/core/util/CoderUtil.java
65.00% <65.00%> (ø)
6.00 <6.00> (?)

...m/baidu/hugegraph/computer/core/common/LongId.java
72.72% <72.72%> (ø)
7.00 <7.00> (?)

...h/computer/core/util/PlainByteArrayComparator.java
81.25% <81.25%> (ø)
6.00 <6.00> (?)

...du/hugegraph/computer/core/util/ByteArrayUtil.java
83.33% <83.33%> (ø)
3.00 <3.00> (?)

...du/hugegraph/computer/core/common/DoubleValue.java
84.21% <84.21%> (ø)
10.00 <10.00> (?)

...aidu/hugegraph/computer/core/common/LongValue.java
84.21% <84.21%> (ø)
10.00 <10.00> (?)

...aidu/hugegraph/computer/core/common/NullValue.java
87.50% <87.50%> (ø)
8.00 <8.00> (?)

...m/baidu/hugegraph/computer/core/common/Utf8Id.java
90.00% <90.00%> (ø)
14.00 <14.00> (?)

...aidu/hugegraph/computer/core/common/ValueType.java
90.00% <90.00%> (ø)
14.00 <14.00> (?)

... and 8 more

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 7675d96...c96ce65. Read the comment docs.


Cannot assign apim_analytics related scopes to a role

Description:
In admin portal it is not possible to assign apim_analytics related scopes and apim:app_update scope to a role, via role permissions page.
Steps to reproduce:

Login to admin portal
Go to settings > Role permissions > Select "Permissions" link on any role >
In the permission trees listed "apim_analytics:*" scopes are are listed, so they can't be assigned.

Affected Product Version:
APIM-3.2.0-RC1
Environment details (with versions):

OS:
Client:
Env (Docker/K8s):

Optional Fields
Related Issues:

Suggested Labels:

Suggested Assignees:

Closing Since the issue has been stale for a long time and is not valid for the latest APIM versions (4.x)


Json based logging by default

Description
Default is now json based logging and no longer text based logging

do you think it could be useful to keep the old construct under a different name, should we have to deal with something that does not log json?

do you think it could be useful to keep the old construct under a different name, should we have to deal with something that does not log json?

I think it's not necessary, because it wouldn't be used at the moment, plus the pattern can be provided as a prop via errorFilterPattern. It'd allow to support any pattern we'd like.


initial commit with basic server, views started with main login html …

…skeleton, and create employee skeleton

submit to early


⚠ ClamAV has degraded performance

In eca741f, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 54 ms

Resolved: ClamAV performance has improved in 2b4b46d after 543 days, 18 hours, 38 minutes.


[QUESTION]  Add attributes to th or td tags

Version: 2.18.0
What browser?
Firefox/chrome...
Expected Behavior
It's possible to add attributes to th  and td rows?
Like:
 or
Thanks

I'm interested in this, too, to add custom rowspan-Attribute.


Add notification banner message when there is a new version of ANET

When a new version of ANET is published, it is problematic for users that leave their browsers open overnight, they end up with a version out of sync.
Have ANET check for new versions, and when the case, automatically reload the client if the page contains no unsaved data.
Add notification banner message when not possible
related to #3019 and #1164

The primary challenge on this issue is to detect when a new version is published. Version number must, somehow, come from server. There are two possibilities here;

Server pushes version number to client whenever a new version is deployed. Can be implemented in several ways:

Websockets

Advantages:

Clients gets notified about new versions immediately.
Easy to implement on client-side with small overhead.
Can also be used for offline detection (#1164)

Disadvantages:

Requires dedicated changes on server-side.
Might be overkill (unnecessarily resource intensive) just for version updates.

Web Push API

Advantages:

Standard, well recognized API
Clients gets notified about new versions immediately.
Easy to implement on client-side with medium overhead.
Once implemented can be used for other use cases (such as notifying user for new published reports)

Disadvantages:

Requires permission from user on user agent. If user declines, whole thing falls down.
Requires dedicated changes on server-side, probably with medium/large overhead.

Client asks/fetches/pulls current version number from server and compares it to the last version it knows to detect if there is an update.

Adding a dedicated GraphQL API for client version.

Advantages:

Clients gets notified about new versions almost immediately.
Can be implemented side-by-side with #3019
If version field can be added to all server graphql responses whole thing can be implemented with minimal overhead. (TODO: clarify)

Disadvantages:

If version is not send with every response then we need to poll it. Polling has a major trade off:

Short polling intervals results in more immediate new version detection while consuming more resources (i.e. unnecessary requests)
Long polling intervals results in delayed new version detection while consuming less resources.

Utilize Service Workers for update management. example

Advantages:

Standard API, widely used for SPA version updates.
Whole thing can be implemented client side. (TODO: make sure about this)

Disadvantages:
2. A bit difficult to implement.

NOTE: This proposal is not finalized, it is still in progress.

As we are using mainly graphql, I suggest graphql subscriptions.


Enable to use GenericTransformation with a null joint2

@nim65s can this patch be pushed in robotpkg when merged ?

@nim65s can this patch be pushed in robotpkg when merged ?

@nim65s could you add this patch to robotpkg ? It is independent of any other changes.

Done: robotpkg-hpp-constraints 4.9.0r1 is available. sorry for the delay :/

Thank you.


Able to not restart RKE2 servers/agents when upgrading a rancher server

Is your feature request related to a problem? Please describe.
This was spotted when Harvester upgrades its embedded rancher service: https://github.com/harvester/harvester/issues/1707#issuecomment-998484833
After bumping rancher's to a newer image, RKE2 servers/agents are restarted due to machine plans change (RESTART_STAMP changes, code path might be here, not quite sure)
Restarting the server or agent can cause a node to enter NotReady status and fails a Longhorn volume.
Describe the solution you'd like

The ability to avoid restarting RKE2 server/agent when the rancher server is upgrading, or
A guideline on how to avoid this.

Describe alternatives you've considered
Stop rancher-system-agent before upgrading rancher.
Additional context

@bk201 Do you have any more details on the exact situation where you're seeing rke2-* restart? Rancher shouldn't be changing the RESTART_STAMP unless the plan changes in a significant manner.

@Oats87 Thanks for the reply. It happened when upgrading from v2.6.3-rc4 to a later head version (supposed to be a version before the formal v2.6.3 release. Sorry we didn't record the exact version). When I saw this behavior, I noticed some rancher-generated RKE2 config files changed.

As these are unofficial/unsupported releases, it is very likely that we changed config file generation (i.e. changed some of the config files) which caused the restart stamp to change between the versions of Rancher. In GA releases, we shouldn't experience this; however, I would argue that Longhorn/Harvester should be able to elegantly handle Kubelet restarts (when rke2-agent is restarted, the kubelet is restarted).

@bk201 , is this something that can be closed based on this comment: https://github.com/rancher/rancher/issues/36523#issuecomment-1055649525 ?

@Oats87 Do you mean the RESTART_STAMP won't change when upgrading from 2.6.3 to 2.6.4?

I would argue that Longhorn/Harvester should be able to elegantly handle Kubelet restarts (when rke2-agent is restarted, the kubelet is restarted).

Longhorn did have an enhancement to this problem (available in 1.2.4). Harvester 1.0.0 still uses Longhorn 1.2.3 and we want to make sure we don't see this problem when upgrading to the next version.

Close this one since we ship Longhorn 1.2.4 in Harvester 1.0.1 and it has the enhancement.


BBS type keeps resetting...

I'm using secure websocket in icyterm, but it keeps resetting to telnet with the 8080 port and won't connect.  Every time I start the program back up, I manually have to change this.  It's annoying, but I'm getting used to it.

Should be fixed in later (read: current) 0.7.6 builds.

I released 0.7.6 a bit too early - I fixed some minor issues after the release.
However SSH is still a problem - I switched the library because of technical reasons. Will release 0.7.7 when I sorted that out.


Philips Hue Smart button support

Hello,
Please add support for the Philips Hue Smart button.
Link to product
Product information from when i added it as generic zigbee device in homey.

Hi @christian-ek, thanks for your request. It's already on my todo list and hopefully soon supported. : ) // Johan

oops... closed by misstake :) Will keep the case open until device is added.

Added to version v.2.0.11


As a user, I want to be able to learn what cyberbullying is through a video, game, and activity

What?

One video scene
One game (multiple scenes?)
One activity (number of scenes to be determined)

Why?

Learn about the basics of cyberbullying

Have the mvp, will be working on clean up


Refactored BatchPoster to generalize handling record types that do not support batch loading APIs (eg. Authorities and Organizations)

A minor tweak in service of handling single-record API types. Refactored to generalize existing handling for authorities to any type that doesn't have a batch API:

Replaced post_authorities method with post_single_records
Added a "is_batch" attribute to list_objects "choices" objects

Implements #454

I am merging it now Brooks. Do you need a release as well?

@fontanka16 No, I don't think so. This was just to help @branchedelac with the orgs functionality. It will need to be merged into that work and further enhanced to add orgs to the type list.


New taco recipe with Mexican chicken

New recipe for the taco cookbook
This closes #18

Great recipe!


Linking the objects (discord API structures) together

For example: In the Message structure there is a property called channelID. In this case, replace this with an actual Channel structure object

Fixed by PR #8, issue #7.


Use SurveyRepository.activeSurvey?.id and not  LocalValueStore.lastActiveSurveyId to get current survey id

Fixed by #1616.


Weird symbols as icons

I'm getting weird symbols as my icons (e.g. E5FF etc.). I'm on Ubuntu and have a patched font installed (using JetBrainsMono) so I'm not sure why it's not working.

Fixed.
Initially I installed JetBrains Mono by following the instructions on https://github.com/ryanoasis/nerd-fonts/blob/master/patched-fonts/JetBrainsMono/font-info.md
The command I ran was:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/JetBrains/JetBrainsMono/master/install_manual.sh)"
I fixed the issue deleting the files installed by the command above. I then downloaded and installed the files from: https://www.nerdfonts.com/font-downloads


Unittest_actions

Hopefully Fix #241.

Humm... it passes but there is still this error:
TypeError: raggedarray_tests.setUpClass() missing 1 required positional argument: 'self'

so there is probably still something wrong.


One server to rule them all

Merge the two servers into one that would listen on both REST and gRPC interfaces.

I just merged this. I've added instructions in the README that explain how to run the new server binary.


Weather

(half the commits carried over from studyspaces, should be merged with current master already)

Use git cherry-pick to have a clean branch based off of master, always base your branches off of master


Update globalization docs regarding shared resources

Here is my example (did cost me a few hours pf my life to figure out what's going on):
I did set this line services.AddLocalization(options => options.ResourcesPath = "Resources");
And then, this works:
services.AddMvc()
                .AddDataAnnotationsLocalization(options =>
                {
                    options.DataAnnotationLocalizerProvider = (type, factory) =>
                    {
                        var assemblyName = new AssemblyName(typeof(DataAnnotations).GetTypeInfo().Assembly.FullName);
                        return factory.Create("DataAnnotations", assemblyName.Name);
                    };
                });

This does not work:
services.AddMvc()
                .AddDataAnnotationsLocalization(options =>
                {
                    options.DataAnnotationLocalizerProvider = (type, factory) =>
                        factory.Create(typeof(DataAnnotations));
                });

The latter scenario will work though, if you remove the ResourcesPath. This should be clearly stated on the documentation as it is very confusing at the moment.
Originally posted by @vocko in https://github.com/dotnet/docs/issues/16964#issuecomment-675900949

@lvmajor commented in the original issue:
Shouldn't this be well documented/clearly indicated in official globalization docs? Specifically in the Using one resource string for multiple classes part where if performing this as recommended, it won't work at all (that is simply creating a class named SharedResource.cs and placing it in the Resources folder along with the other resx files)

One more note, the first case only works when the type class is in AssemblyName.Resources namespace. If you want to nest it deeper into the folder structure and keep the standard namespacing pattern, you have to update the class name parameters for the IStringLocalizerFactory.Create method with the full namespace relative to the assembly name.
For example consider the file structure is as follows (DataAnnotations namespace will be AssemblyName.Resources.Shared.DataAnnotations):

Resources

Shared

DataAnnotations.cs
DataAnnotations.resx
DataAnotations.cs.resx

services.AddLocalization(options => options.ResourcesPath = "Resources");

services.AddMvc()
    .AddDataAnnotationsLocalization(options =>
    {
        options.DataAnnotationLocalizerProvider = (type, factory) =>
        {
            var assemblyName = new AssemblyName(typeof(DataAnnotations).GetTypeInfo().Assembly.FullName);
            return factory.Create("Shared.DataAnnotations", assemblyName.Name);
        };
    });

Please update the documentation as this is not obvious and the current given example doesn't work.


Error 503 for all requests

Because of a new implemented CDN to protect the Intra, all requests from the My Intra app are refused.


Log result UI needs improvement - word-wrap, remove unnecessary columns, auto-sized column width

Can you please make the log result UI improved so users can actually see the logs?
I would suggest the following as the high priority.
(1) Each row must support the word wrap. A long log line is not displayed fully. This is the most serious issue.
(2) Remove the columns of "status", "id". I am not sure what is "status" field and no users would care about the log id.
(3) Remove the "level" column or make it accurate.
(4) The column width should be auto-sized. Otherwise, users will have to keep resizing it.

Hi @tonychoe,
The latest version of the oci-grafana-logs plugin addresses some of your comments and the rest I believe can be addressed through other Grafana capabilities. Here is an explanation for how each of the items you raised is addressed:

Text wrap within cell

This is not a characteristic of the presented table that the datasource plugin has control over.
This needs to be managed through the Table panel plugin however this is a known issue with the Grafana table panel plugin, see https://github.com/grafana/grafana/issues/25623.

Remove status & id columns

The status column has been removed since the plugin now only displays the fields that are actually present in the returned log records. Which means the plugin does not try to derive fields such as 'status' that prior versions of the plugin did.
The 'id' column still exists since the plugin has been updated to only show the fields present in the returned log records and the 'id' field is one that is included in the log records returned by a logging search query.
However the 'id' column (or any other unwanted column) can be hidden using the "Organize fields" transformation.
This transformation can be used to control many other aspects of the presented table including hiding columns, re-ordering columns, etc.

Remove the level column

As referenced in the response to the last item, the plugin has been updated to only show the fields present in the returned log records which means that the level column is no longer shown (unless there is a level field within the returned log records).

Column width should be auto-sized

Column width auto sizing can be controlled via the Panel Options when editing the data panel configuration. The related configuration settings are available under the Table portion of the panel configuration options.
The width of individuals columns can be separately adjusted and the selected width is retained by the Table panel so when the panel is displayed again the same column width is used.

Please try the updated oci-grafana-logs plugin and other Grafana features to determine whether all of your points are addressed. Let us know if you believe that any of the issues are still not addressed. If no response is received within 30 days, this issue will be closed.
Thanks

Since no follow up was received, this issue is being closed. If at a later point in time you are able to test a newer version of the plugin and still have issues related to this or any other topic then please submit a new issue.


new v 10 and new md5 and new file name

dont updated AdditionalInstallSize dont sure what is this

AdditionalInstallSize is the size of all extracted files. Just extract the zip archive and go to the properties of the folder to get the amount of bytes.
Please update the version information in App\AppInfo\appinfo.ini as well (PackageVersion is the version which is displayed if you click properties -> details on the PhpStorm.exe).


Replace config.json with config.yaml

This is a suggestion only :-)
Unfortunately the JSON file format doesn't allow any comments and I would like to suggest the use of YAML
WHY?
I find it laboriously as a noob to keep separate notes and would appreciate it very much to have the possibility to comment things I change in config.json, as my old brain is not so fit anymore :-)
Especially the entries for "avoid" and "exclude" which are pubkeys.

I like the idea of having comments in the config file. Collecting feedback from the alpha-testing group.

There's a library that allows reading json with comments: https://www.npmjs.com/package/comment-json
There's also JSON5.
Perhaps it's worth considering these options unless YAML is preferred.


NadekoInstaller.bat not downloading

Following the guide someone gave me here
https://discordbeats.readthedocs.io/en/latest/guides/Windows Guide/
When I get to the "save link as" part, NadekoInstaller.bat does not install. This is all I can say, as it is all that I know.
As an update, the FFMPEG link does not work for me either.

Apparently, the repo that has that file is gone. Kwoth is probably doing something.

Thanks

that's a fork of nadeko. Not real nadeko.


Maven-repo-cache autofix broken in new version

Autofixes failed with ENOENT: no such file or directory, stat '/opt/app/build/lib/resources/dot-atomist': Ignoring failure

I don't think lib/resources is copied into build anymore.  It might be /opt/app/lib/resources/dot-atomist now?

cd @kipz

cool, closing


modem: modem_cmux: Set C/R bit in UIH frames

This PR updates the modem_cmux module to set the C/R (command/response) bit when UIH CMUX frames are sent from the modem_cmux module. This bit is ignored by some modems like the Quectel BG95, as there is no defined response to this specific CMUX frame type, other modems like the TELIT ME910, require the bit to be set. If the bit is not set, the TELIT ME910 modem simply ignores the frame.
The PR also aligns the unit tests with the new behavior, updating both the C/R flag and the FCS field of the CMUX frames.
I have tested the fix on a Quectel BG95, @JeffWelder has tested the fix on a TELIT ME910
fixes: https://github.com/zephyrproject-rtos/zephyr/issues/63577

Solves https://github.com/zephyrproject-rtos/zephyr/issues/63577

added labels and modified OP to indicate that this PR is fixing a bug


raise an error if -c argument is used in rasa train

Rasa version: master
Python version: 3.7
Operating system (windows, osx, ...): macOS
Issue:
If -c argument is used, but config file cannot be found, rasa train uses default config, I think it is better to raise an error instead

@Ghostvv This was actually a feature request from @erohmensing (see https://github.com/RasaHQ/rasa/issues/3272).
Currently,

if you train without any config a default config is used
if you train an NLU model and your config misses the parameter pipeline, the config gets enriched with the default pipeline
if you train a Core model and your config misses the parameter policies, the config gets enriched with the default policies
if a complete and valid config is provided, that config is taken

So, in case 1) we should not use the default config but raise an error. Is that correct? Or should we only raise an error if you specify the config via -c and the specified config is incomplete/invalid? And in case you did not specify the config via -c, but there is also no config.yml in your project, it is still fine to use the default config.

I think if -c is specified, but there is smth wrong, we should raise, otherwise use default with a warning maybe


Remove Annotations Button with hidden marker still displayed

@TS-Tino16 seems like the wrong remove annotations button is hidden. In this example the first marker is hidden (timeline and description and annotations are hidden), but the remove button from the last marker (third) is hidden and not the first one. Can you check that?


Barcode scan record lookup example LWC

Created an example LWC that looks up a record with matching barcode and show the record.

Going to try to have @akong-sf open a new PR, to see if that clears things up with the CLA bot.


Add filename to export

It's useful if we include the filename in the export.

Added filename to exports in 1.0.3


Contacts field in add team form not populating

Environment

Nautobot version (Docker tag too if applicable): v2.2.0a1
Python version: n/a
Database platform, version: n/a
Middleware(s): n/a

Steps to Reproduce

Navigate to any device's contacts tab
Click add a new contact
Go to the Add a new team tab
Click the dropdown for contacts

Expected Behavior
API call to /api/extras/contacts

Observed Behavior
API call to /api/extras/teams
FIX
Typo in the queryset kwarg here

Implemented by #5358


Generate constructors

Yeah, docs in general are a definite TODO item for the project. I would say the current state is only because it started off as a prototype.


Non transactional methods should have a return type

Fixes #874
🚀 Description
This fix simply returns true should the method succeed. This should not affect the situation where the original behaviour was desired (ie. where a role does not have access) as the associated require() call should cause a premature revert prior to return.
Second pull request (I rejected my first one), apologies for the log messiness, wanted to ensure only the minimal change was committed.

[X] 📘 I've reviewed the OpenZeppelin Contributor Guidelines
[X] ✅ I've added tests where applicable to test my new functionality.
[X] 📖 I've made sure that my contracts are well-documented.
[X] 🎨 I've run the JS/Solidity linters and fixed any issues (npm run lint:all:fix).

Closing as this seems to be a bug in web3j. If necessary let's continue discussion in #874.


Selects

Is correct for remove the "is-focused" class after making the selection add this?
setName () {
  ...
  this.$els.textfield.classList.remove("is-focused")
}

It took me some time to understand that 😅
Yes, we should remove it. The best way is to call the MDL method for it: this.$els.textfield.MaterialTextfield.boundBlurHandler()

Ok, Thanks for the great job.

If you want to create the PR and need some help, I'm willing to do so 😄


Support Python 3.11

Codecov Report

Merging #155 (58a1a4b) into master (8fa247f) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master      #155   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            6         6
  Lines          201       201
  Branches        23        23
=========================================
  Hits           201       201

Impacted Files
Coverage Δ

src/citric/client.py
100.00% <ø> (ø)

src/citric/method.py
100.00% <ø> (ø)

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 8fa247f...58a1a4b. Read the comment docs.


Produce better errors when parsing config

Codecov Report
Base: 3.44% // Head: 2.63% // Decreases project coverage by -0.81% :warning:

Coverage data is based on head (c59f5b3) compared to base (c7f04b0).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff            @@
##            main      #2      +/-   ##
========================================
- Coverage   3.44%   2.63%   -0.82%
========================================
  Files          2       2
  Lines         58      76      +18
========================================
  Hits           2       2
- Misses        56      74      +18

Flag
Coverage Δ

unit
2.63% <0.00%> (-0.82%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/lib.rs
2.22% <0.00%> (-1.49%)
:arrow_down:

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.


Bitbucket IP range check not working

Thanks for providing this very useful tool!
I trying to use a webhook from Bitbucket, as explained on the examples. But using the IP range for whitelisting, the response is "Hook rules were not satisfied.". Removing the whitelist restriction, everything works fine.
I was expecting, that running webhook --hooks /etc/webhook.conf -verbose to see the IP address of the requesting servers, but this is not the case. Since Bitbucket also offers IPV6 IP addresses, it maybe the case, that they maybe used.
Is there any way to determine the IP address of the requesting servers? Is IPV6 supported?
Thanks for your feedback.

Hey, thanks for using webhook :-)
I will add IP logging support in the next release. I agree that it's a valuable piece of information that you currently cannot see in the logs. Currently, the only way to check for the incoming IP is to set up a proxy in front of webhook that would pass it down via the header, or, shut down webhook and start up a netcat on the port webhook is listening on and see the ip :-)

@adnanh Thanks for your feedback and for adding IP logging in future releases. I'll dig into netcat. Thanks for the idea.

I looked into it with nc -l 9000 -v. BitBucket sent requests with <IP_ADDRESS> and <IP_ADDRESS>. I'm using the exact sample piece from the example:
"trigger-rule":
{
  "match":
  {
    "type": "ip-whitelist",
    "ip-range": "<IP_ADDRESS>/24"
  }
}

The response I see at BitBucket still is Hook rules were not satisfied. - since this is the only rule, I'm wondering why this doesn't match and work?
Maybe you have a chance to try it on your side?

I'll try it out as soon as I get some free time :-)

It appears to be working for me. Could you please post the full hooks json file?

Also, I've released 2.6.4 with the IP logging feature

@adnanh Thanks for taking the timing! My configuration looks like:
[
  {
    "id": "puppetmaster-webhook",
    "execute-command": "PATH_TO_EXECUTABLE",
    "command-working-directory": "PATH_TO_WORKING_DIRECTORY",
    "include-command-output-in-response": true,
    "trigger-rule":
    {
      "match":
      {
        "type": "ip-whitelist",
        "ip-range": "<IP_ADDRESS>/24"
      }
    }
  }
]

So it's just the example taken from the "Hook examples". The response at Bitbucket displays "Hook rules were not satisfied." as body content.
Since I use Ubuntu packaging to install and run webhook, could you give me short instruction howto update to the latest version? Since it's Go bases, I could just download the latest executable, right?

Yes, depending on your ARCH, all you need is to download the appropriate webhook-linux-ARCH.tar.gz from the Releases tab. (Most likely it'll be this one: https://github.com/adnanh/webhook/releases/download/2.6.4/webhook-linux-amd64.tar.gz)

Thanks for taking the time investigating this in more. It works for me with the new release, but not with the old, with the same config:
New version, without IP whitelisting in config
[webhook] 2017/06/08 14:59:46 incoming HTTP request from <IP_ADDRESS>:61525
[webhook] 2017/06/08 14:59:46 XYZ-webhook got matched
[webhook] 2017/06/08 14:59:46 XYZ-webhook hook triggered successfully
[webhook] 2017/06/08 14:59:46 executing /... (/...) with arguments ["/.."] and environment [] using /etc/.../code/ as cwd
[webhook] 2017/06/08 14:59:48 command output:
[webhook] 2017/06/08 14:59:48 finished handling XYZ-webhook
[webhook] 2017/06/08 14:59:48 2017-06-08T14:59:46Z | 200 | 	 1.591855914s | SERVER:9000 | POST /hooks/XYZ-webhook

Here I changed the config to enable IP whitelisting.
New version, with IP whitelisting in config
[webhook] 2017/06/08 15:00:46 incoming HTTP request from <IP_ADDRESS>:63008
[webhook] 2017/06/08 15:00:46 XYZ-webhook got matched
[webhook] 2017/06/08 15:00:46 XYZ-webhook hook triggered successfully
[webhook] 2017/06/08 15:00:46 executing /... (/...) with arguments ["...t"] and environment [] using /etc/.../code/ as cwd
[webhook] 2017/06/08 15:00:47 command output:
[webhook] 2017/06/08 15:00:47 finished handling XYZ-webhook
[webhook] 2017/06/08 15:00:47 2017-06-08T15:00:46Z | 200 | 	 1.739314364s | SERVER:9000 | POST /hooks/XYZ-webhook

Back to old version, with IP whitelist enabled
[webhook] 2017/06/08 15:01:51 Started POST /hooks/XYZ-webhook
[webhook] 2017/06/08 15:01:51 XYZ-webhook got matched
[webhook] 2017/06/08 15:01:51 XYZ-webhook got matched, but didn't get triggered because the trigger rules were not satisfied
[webhook] 2017/06/08 15:01:51 Completed 200 OK in 387.294µs

Back to new version, with IP whitelist enabled, with invalid IP
[webhook] 2017/06/08 15:06:56 incoming HTTP request from <IP_ADDRESS>:52148
[webhook] 2017/06/08 15:06:56 XYZ-webhook got matched
[webhook] 2017/06/08 15:06:56 XYZ-webhook got matched, but didn't get triggered because the trigger rules were not satisfied
[webhook] 2017/06/08 15:06:56 2017-06-08T15:06:56Z | 200 | 	 127.205µs | SERVER:9000 | POST /hooks/XYZ-webhook

The problem seems to be solved for me, but I'm wondering if you changed more than just adding logging of the IP address?
Thanks again for your time!
I anonymized paths and server name

Nope, I literally fixed tests that were failing due to bad fixture. Here are the 2.6.4 changes: https://github.com/adnanh/webhook/commit/a38875213a92171fd9779629f77375691ee2b9c9

Does the trigger rule fail in the new version when you hit it from an IP that is not whitelisted? Did you compile both versions from source? I might have upgraded Golang version in between them on my laptop...

I'll close this issue for now as it appears to be fixed in 2.6.4. Feel free to reopen if it resurfaces again...


Reflect ETCM-396 faucet config changes

Adapts faucet config to https://github.com/input-output-hk/mantis/pull/829

LGTM!


Pretraind model download

Hi,
I'm trying to download the weights of the pre-built model as described in the Searching proteins guide. Unfortunately, wget fails as follows:
wget https://users.flatironinstitute.org/thamamsy/public_www/tm_vec_cath_model.ckpt
--2024-05-13 13:55:58--  https://users.flatironinstitute.org/thamamsy/public_www/tm_vec_cath_model.ckpt
Resolving users.flatironinstitute.org (users.flatironinstitute.org)... <IP_ADDRESS>
Connecting to users.flatironinstitute.org (users.flatironinstitute.org)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: /~thamamsy/tm_vec_cath_model.ckpt [following]
--2024-05-13 13:55:59--  https://users.flatironinstitute.org/~thamamsy/tm_vec_cath_model.ckpt
Reusing existing connection to users.flatironinstitute.org:443.
HTTP request sent, awaiting response... 403 Forbidden
2024-05-13 13:55:59 ERROR 403: Forbidden.

Do you have an alternative download link or method I could try?

Hi thanks. We are currently shuffling around datasets in preparation for the new release.
In the meantime the TMvec and DeepBLAST checkpoints can be found on fig share
https://figshare.com/articles/dataset/TMvec_DeepBLAST_models/25810099

The download from figshare works perfectly.
Thanks!

Hi @mortonjt,
I'm having another download problem. This time I'm trying to download the available databases. Neither CATH S100 nor Swissprot are available, due to a 403 error similar to the one I reported before.
I also tried to build my own database from Swissprot, but ran out of memory as reported in #141 .
It looks like downloading a pre-built database is the only way to go. Could you please provide some updated links?
Thanks

Hi, I've uploaded the Swissprot database here : https://zenodo.org/deposit/11199459
Sharing the protrans embeddings is currently difficult, since zenodo timing out. More to come.

Hi, thanks for the upload! Zenodo complains, however, that "You do not have sufficient permissions to view this page."

That was a typo above, it should be records give it a shot now

Works now, thanks!


Uninstall not showing up

Hi! Here in the documentation, it says that in the "reports" area, there should be a section called "Uninstall", but I don't see such section in my interface. Is there any reason to it? I'm trying to see the uninstall info of this VSCode extension https://marketplace.visualstudio.com/items?itemName=JeronimoEkerdt.color-picker-universal

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: efabb28f-dde3-6955-f5b2-d43e28318fe2
Version Independent ID: 9e456835-9faa-0434-bd51-b85c42e37bf2
Content: Extension Report - Azure DevOps
Content Source: docs/extend/extension-report.md
Service: azure-devops
Sub-service: azure-devops-ecosystem
GitHub Login: @chcomley
Microsoft Alias: chcomley

Related issue https://github.com/MicrosoftDocs/azure-devops-docs/issues/10195

@jeronimoek -- Jeronimo, thank you for your feedback and research.  Please consider these resources, if you haven't already:

Azure DevOps Services
Azure DevOps on Stack Overflow

@chcomley -- Chrystal, please look into this potential documentation issue.

Hi @jeronimoek, it's been quite a while, but I wanted to address your question. Azure DevOps doesn't have information on Visual Studio code extensions. This article is only for Azure DevOps extensions. Thanks so much.


Integration with updater

I tried to use the factorio update command with [this](Integration with ) repository but could not get it to work.
The problem always is that somehow your script overwrites the UPDATE_SCRIPT env variable with /path/to/update_factorio.py and then can not find the script. also your test if the variable is set is not correct imho. It should be
 if  [ -z "${UPDATE_SCRIPT}" ]; then

instead of
 if ! [ -e "${UPDATE_SCRIPT}" ]; then

I tried to even set the value of UPDATE_SCRIPT  directly in the script with: export UPDATE_SCRIPT='...'. This worked in the first few lines, but was overwritten till the call of the update function.
Can I help you there somehow?
I really love the tool so far. Currently I solved it with using another env variable UPDATE_SCRIPT2 which works like a charm.

Hi, a bit of a late reply - but did you try to set the path in your config file? (that's the only place where this script sets the value of this variable), also, the check is not for the variables existence - it checks to make sure the script at the path exists and is executable "-e".
Feel free to re-open this if you still have the same problems after setting the path in your config file :)

I'm not using this anymore so can not tell


Increase the Accuracy of Facial Emotion Recognition model

I would like to increase the accuracy of facial emotion recognition model and propose different models. I would also like to train the model on the Affectnet Dataset.
Different Models Include :
1: Custom Model in which there are 7 layers
2: Inception_V3 Model Fine-Tuned for facial Recognition

I am GSSOC 23 contributor assign this to me i want to work on this

Hello, I'm GSSoC'23 Contributor. Please assign me this issue. I want to work on this and contribute to this.

assigned


migrate away from request

:clipboard: Description
Request is no longer maintained:
https://github.com/request/request#deprecated

As of Feb 11th 2020, request is fully deprecated. No new changes are expected to land. In fact, none have landed for some time.

We need to switch to a different library. This is going to be an absolutely monstrous job.
@calebcartwright you mentioned in https://github.com/badges/shields/pull/4644 that there has been some discussion around this already. I couldn't find an issue anywhere. Do you have any kind of summary of where we've got to on this. I'm aware its somewhat complex as our use of the library is quite involved, there are many other libraries we could potentially migrate to, and none are an obvious like-for-like replacement for request.

@calebcartwright you mentioned in #4644 that there has been some discussion around this already. I couldn't find an issue anywhere.

I believe it was in one of the private channels on Discord, will try to dig it up. IIRC we didn't go into much detail, just that it'd need to be replaced and that we'd have to keep in mind Self-hosting Shields server users which currently benefit from requests ability to auto-detect and honor the standard proxy env vars (something I believe is missing from most request alternatives

This is related to #3368, but yea, I remember @calebcartwright mentioning the limitations in proxy support in other HTTP clients. That was a while ago. I wonder if there is a solution for any of those now.
Should we merge these two issues?

Should we merge these two issues?

Yeah sorry. They are probably the same thing.

It seems like we should open a new issue which combines the scope of both. Request being unmaintained is making this more urgent than it was before, and deserves high billing, although the first order of business is probably to test the effectiveness of that memory cache.

We talked a bit the other day about some of the mechanics of this (e.g: an adaptor layer that allows our service code to use request-style params with another library), but it seems like a very major decision we need to make is which library we're going to migrate to. While its on my mind, I'll post this link to discussion of possible alternatives as a starting point, but in making this choice we also need to try and work out what our requirements even are (what is the current subset of the request feature set we depend on?)

In my experience, the main differentiator with request that has folks still using it to this day over alternatives is the auto-detection and honoring of the standard proxy env vars (http_proxy, https_proxy, no_proxy). The other client libs require explicit in-code proxy specification and/or additional libraries to get the same behavior.
Proxy support is an important requirement for self-hosting Shields, though admittedly not relevant for the Shields.io service.
FWIW at this point I expect most (if not all) of the alternative prominent client libs will have the core features we'd need, and I'm guessing it will likely boil down to ergonomics and ease of request-replacement in our codebase

We talked about this again in the ops meeting today.
One of the blockers to this is that we've failed to make a decision on which library we're going to use and basically the outstanding issue is proxying..
Just re-reading the thread, basically the deal is: request configures proxying based on the http_proxy/https_proxy/no_proxy env vars. If we go to another library (lets say got for the sake of argument) we have to explicitly configure proxying: https://github.com/sindresorhus/got#proxies
So it sounds like the options if we move to another library are:

We say "breaking change for self-hosting users as of version X* you can't use http_proxy/https_proxy/no_proxy any more you have to do [something else]" (TODO: what is [something else]?)
We read values from http_proxy/https_proxy/no_proxy ourselves and use them to optionally configure hpagent (or whatever) because got can't do it for us. i.e: we have to re-implement a feature that exists in requests but we could avoid a breaking change for users that rely on it.

*lets abstract the fact we don't have a good method for doing this at the moment and assume it is covered under https://github.com/badges/shields/issues/5866
@calebcartwright  do you have any input on either of those options? If you can flesh either of those things out a bit, great - that would help. If not, even confirming that is useful. We will at least know what the next things we need to research are..

We talked about this again in the ops meeting today.
One of the blockers to this is that we've failed to make a decision on which library we're going to use and basically the outstanding issue is proxying..
Just re-reading the thread, basically the deal is: request configures proxying based on the http_proxy/https_proxy/no_proxy env vars. If we go to another library (lets say got for the sake of argument) we have to explicitly configure proxying: https://github.com/sindresorhus/got#proxies
So it sounds like the options if we move to another library are:

We say "breaking change for self-hosting users as of version X* you can't use http_proxy/https_proxy/no_proxy any more you have to do [something else]" (TODO: what is [something else]?)
We read values from http_proxy/https_proxy/no_proxy ourselves and use them to optionally configure hpagent (or whatever) because got can't do it for us. i.e: we have to re-implement a feature that exists in requests but we could avoid a breaking change for users that rely on it.

*lets abstract the fact we don't have a good method for doing this at the moment and assume it is covered under https://github.com/badges/shields/issues/5866
@calebcartwright  do you have any input on either of those options? If you can flesh either of those things out a bit, great - that would help. If not, even confirming that is useful. We will at least know what the next things we need to research are..

@calebcartwright do you have any input on either of those options?

I've become pretty partial to got personally, and given that we already make use of it within this project I'd lean towards trying to make that work as the replacement for request.
The only thing I feel strongly about is that we need to maintain the ability for self-hosted instances to work with proxies/network restricted environments; otherwise a core use case for self-hosted is largely defeated. I don't recall specifics offhand, but there's cases of libs (and/or their internal deps which support proxies) utilize env vars for configuration, just not the standard ones (e.g. it won't pick up http_proxy but instead looks for something like my_awesome_lib_http_proxy). I'd be fine with a posted breaking change that basically requires users to incorporate new env vars in their deployment. This of course depends on the selection of the client lib replacement.
If we end up using a replacement that doesn't have any auto detection, then yes I'd think either adding some new configuration options we support and/or auto mapping from the standard vars would be a viable option.
I'd suggest we select the request replacement based on what will work best for Shields, provided said replacement can be configured to support proxies, and then just take the work on the proxy piece forward based on the contexts and constraints of that replacement we're targetting

@calebcartwright do you have any input on either of those options?

I've become pretty partial to got personally, and given that we already make use of it within this project I'd lean towards trying to make that work as the replacement for request.
The only thing I feel strongly about is that we need to maintain the ability for self-hosted instances to work with proxies/network restricted environments; otherwise a core use case for self-hosted is largely defeated. I don't recall specifics offhand, but there's cases of libs (and/or their internal deps which support proxies) utilize env vars for configuration, just not the standard ones (e.g. it won't pick up http_proxy but instead looks for something like my_awesome_lib_http_proxy). I'd be fine with a posted breaking change that basically requires users to incorporate new env vars in their deployment. This of course depends on the selection of the client lib replacement.
If we end up using a replacement that doesn't have any auto detection, then yes I'd think either adding some new configuration options we support and/or auto mapping from the standard vars would be a viable option.
I'd suggest we select the request replacement based on what will work best for Shields, provided said replacement can be configured to support proxies, and then just take the work on the proxy piece forward based on the contexts and constraints of that replacement we're targetting

For example, got will work with global agent which can pick up custom env vars:
https://github.com/gajus/global-agent#environment-variables
Or with one minor additional env var, be configured to pick up the standard vars:
https://github.com/gajus/global-agent#what-is-the-reason-global-agentbootstrap-does-not-use-http_proxy

For example, got will work with global agent which can pick up custom env vars:
https://github.com/gajus/global-agent#environment-variables
Or with one minor additional env var, be configured to pick up the standard vars:
https://github.com/gajus/global-agent#what-is-the-reason-global-agentbootstrap-does-not-use-http_proxy

Good shout on global-agent. That sounds like it would resolve the one outstanding issue

Good shout on global-agent. That sounds like it would resolve the one outstanding issue

OK then. I've spent a bit of time thinking about this and playing with things. Aside from request and got I think there are really 3 other libs in the Node JS ecosystem worth looking at: axios, node-fetch and superagent.
Obviously one of the things we want to optimise for is performance, but it isn't the only thing that is important (if it was, we'd just stick with request forever). We also want a project which is actively maintained and some kind of reasonable expectation that this thing is still going to be around in the future. As we're in the process of doing this it is clear that changing our HTTP client is a big job. If we pick something that is memory efficient but then we end up going through this same process a year or two down the line that is counter-productive.
I did a bit of testing making some calls with various HTTP clients and process.memoryUsage().heapUsed dotted about. It is hard to compare like-for-like. I'm not sure how scientific it was and I don't think we're really going to find out how each lib performs with a real production workload without putting a real production workload through it. Those caveats aside, based on those tests I think axios is going to perform similarly to got but node-fetch and superagent will probably be somewhere in the middle of request and got. So I've discounted axios. Node-fetch and superagent are probably the two worth thinking about more. I think switching to any other library will result in an increase in memory usage compared to request.
In terms of picking, there are a few considerations:

Node-fetch is more widely used than superagent (~20mil weekly downloads vs ~4mil weekly downloads)
Superagent's interface is an outlier and probably maps less well onto our plan to try and keep a request-like options for now but just use a new library because it uses a fluent interface with lots of chained function calls rather than a config object like got/request/node-fetch/axios. Not an insurmountable obstacle but its more of a gap to bridge than got was or node-fetch would be.
Node-fetch is a pretty lightweight library. In some ways this is an advantage given we are chasing performance. The flip-side is this also means it lacks some nice features that exist in other clients. To give a couple of examples: It doesn't provide an abstraction for HTTP basic auth - if you want to use that you do it by assembling an Authorization header yourself. It doesn't provide an abstraction for querystrings. You have to build your querystring with URLSearchParams and append it to the URL yourself. This stuff is probably all do-able but requires a bit more effort to implement than a more "full-featured" client. There is a risk there might be something we need that it doesn't do and we won't find out until we need it.
Node-fetch basically mimics the interface of the browser standard window.fetch with some extensions. This is all a bit speculative, but there are also some rumblings about implementing fetch() natively in node core. More details at https://github.com/nodejs/node/issues/19393 but tl;dr is the maintainers are fine with adding it in principle and some progress is being made (but slowly). If an implementation of fetch() lands in node core I suspect that probably doesn't mean the end of all third-party HTTP clients like got/axios/superagent but I wouldn't be surprised if it was the end of node-fetch so there's a risk of ending up on another abandoned library there. That said, given they'd both be different implementations of the same interface I'd also hope migrating from node-fetch to er... node fetch() wouldn't be too hard, whereas if we wanted to migrate to a native node fetch() implementation from superagent that would be another huge migration job as the interfaces are so different. So if we envisage things going in that direction, node-fetch is probably a good intermediate step. I guess it could go either way..
One interesting thing about node-fetch in contrast to other clients is that it treats everything as a stream/promise, so to compare superagent and node-fetch:

const superagent = require('superagent')
const data = await superagent.get('https://google.co.uk')
const body = data.text

const fetch = require('node-fetch');
const data = await fetch('https://google.co.uk')
const body = await data.text()  // note we have to await this

I suspect this doesn't really help us much performance-wise because in 99% of cases we need to evaluate the body so it actually probably means we just have to make more code changes to try it. This might allow us to squeeze a tiny bit of extra performance when we are serving an error response (because we only care about the status code, I think) but we might need to make some changes to unlock that.
I think I am leaning slightly more towards trying https://github.com/badges/shields/pull/6160 again with node-fetch but if anyone else has any points to add, please do.. I'll probably give it a few days before diving into this again.

Will be the one to ask the dreaded question.. any difference between those two in terms of proxy support? :laughing:
Would it even potentially be worthwhile to consider using the stdlib modules directly? I know they aren't exactly known for ease of use and great ergonomics, but I feel like the codebase is structured well in terms of sufficient encapsulation that I wouldn't rule out the stdlib out of pocket, especially given the performance emphasis.
Between superagent and node-fetch specifically, think I'd agree with you on node-fetch being the better candidate for a next test.

Will be the one to ask the dreaded question.. any difference between those two in terms of proxy support?

When it comes to proxying, it is the same story for node-fetch and superagent really, which is in turn pretty much the same story as got.
Neither explicitly implement support for the proxy env vars but we should be able to use global-agent.
The difference when it comes to superagent/node-fetch is that although they should work with global-agent, they don't explicitly test against those clients: https://github.com/gajus/global-agent#supported-libraries
so I guess we've just got to try it, but my plan for proxy implementation on our side will be identical to what I did for got.

Would it even potentially be worthwhile to consider using the stdlib modules directly?

I think probably not. I've not really evaluated this option but if we go down that route, we're going to end up writing some kind of abstraction (however thin) over the node core HTTP libs, at which point we're essentially making our own version of got/superagent/node-fetch (admittedly focussing on only a small subset of the features) only it will be worse and maintained by us. I think when it comes to this kind of low-level abstraction there is a huge benefit in using something off-the-shelf instead of home-brewing our own solution. (See ScoutCamp for more details). Sure we are trying to serve a lot of traffic on modest infrastructure but I don't think we are enough of a special unique unicorn that we need to write our own HTTP abstraction for it and I don't really think we'd make a better job of it than any of the big popular projects.

but my plan for proxy implementation on our side will be identical to what I did for got.

:+1: Happy to test this again, just lmk

I think probably not.

Fair enough. I'm not actively pushing for it, and am very much hoping that node-fetch will solve our needs. I know I wouldn't have sufficient bandwidth and motivation to do any kind of research/eval on using the stdlib approach anyway :smile:.
From the sound of it though, I'm probably a bit more open to that possibility. However, we're fully aligned on the plan to go after node-fetch so it wouldn't make much sense for me to articulate why at this time, can always circle back to it if we end up needing to.

Not looked at this in a while, but it is still on my mind.
@paulmelnikow suggested looking at https://github.com/nodejs/undici - it is an interesting option and it is possible the the fetch implementation that eventually lands in core my end up looking like https://github.com/Ethan-Arrowood/undici-fetch (backed by https://github.com/nodejs/undici ). There's a few mins on this at the end of https://www.youtube.com/watch?v=fcj2Z9dL060
The thing with undici (having done a small amount of reading) is that it doesn't use node's (current) HTTP stack internally at all - its a completely from-the-ground-up implementation. This means that nock doesn't work with it and neither will global-agent (nor any other packages that rely on your http client being an abstraction over Node's HTTP internals). Given it doesn't (yet) have support for mocking https://github.com/nodejs/undici/issues/531 that's a blocker for us at the moment plus we'd have to roll our own proxy configuration.
I think that is still leaning me towards node-fetch at the moment (again viewing it as a possible 'stepping stone' to a native fetch implementation) but it is worth keeping one eye on undici as it develops..

I've been having a slightly more detailed think about node-fetch and the featureset we need from it.
In terms of the options of request/got we are currently using:

body: Compatible, but I think we're responsible for JSON.stringify()-ing it ourselves if the body is JSON.
form: There is no 'shortcut' for this. We have to assemble the body ourselves with new FormData().
headers: Compatible
method: Compatible
url: N/A you can't pass it in the options object, but doesn't matter
qs: We're responsible for building it with URLSearchParams and appending it to URL ourselves
gzip: Translate to compress
auth: We're responsible for building an Authorization header ourselves

So all that is do-able (although some of those cases need a bit of work) but here's the thing it doesn't have:

strictSSL: Node-fetch doesn't have the ability to disable SSL checking. We do have some options here. See https://newbedev.com/node-fetch-disable-ssl-verification We should not use process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0" because node is single-threaded. Using a custom Agent should work, but I'm not sure this would be compatible with using global-agent (which also uses a custom agent) for proxying. I'm not sure if they will "stack".

There are currently only two services using this - coverity and jenkins - but it is a non-zero number.
I think the first thing to do on this is research/test the node-fetch/custom agent setting rejectUnauthorized: false/global-agent proxy combo before trying to implement the rest of it.

I started looking at the strictSSL/proxy thing and submitted #6886 and #6887 Maybe we could actually get away with ignoring this issue completely and say strictSSL is a hard requirement moving forwards if we go with node-fetch..

Been dragging this on for a bit, but having tried out both got and node-fetch for a bit with a production workload and evaluated both the performance and library ergonomics the conclusion is to go with got. Once #7175 is merged, I will continue to pick through the remaining instances of request replacing with got.

Keeping track of the instances in https://github.com/badges/shields/issues/4655#issuecomment-794429908 and crossing them off as I do them. 2 more to go. As I'm working on this I realise there are quite a few more tasks. This is mainly for my own reference:

I think we can now probably completely delete https://github.com/badges/shields/blob/master/core/base-service/legacy-request-handler.js :crossed_fingers: but there are still quite a few files that refer to it
Docs: need to update https://github.com/badges/shields/blob/eb07b60cf09676af840b274b4d6ff5260dc1fc3f/doc/code-walkthrough.md?plain=1#L93-L101 and https://github.com/badges/shields/blob/eb07b60cf09676af840b274b4d6ff5260dc1fc3f/doc/code-walkthrough.md?plain=1#L126-L134
Final bits of cleanup once request is completely removed:

Remove requestOptions2GotOptions and switch everything to assume it is talking to got options natively rather than through an adapter
Remove request as a dependency
Update all the places in the docs and docstrings where we are referring to request (e.g: https://github.com/badges/shields/blob/eb07b60cf09676af840b274b4d6ff5260dc1fc3f/core/base-service/base-json.js#L31-L32 and https://github.com/badges/shields/blob/eb07b60cf09676af840b274b4d6ff5260dc1fc3f/doc/TUTORIAL.md?plain=1#L231 etc )

https://github.com/badges/shields/blob/eb07b60cf09676af840b274b4d6ff5260dc1fc3f/core/base-service/base.js#L453

I suspect we are a long way from this feature reaching stability in a LTS node version, but first commit adding experimental undici-based global fetch() landed in node a couple of days ago https://github.com/nodejs/node/commit/6ec225392675c92b102d3caad02ee3a157c9d1b7 :innocent:


DATAGO-74463: Add Dynamic Producer Destination to the binder

Description
##Overview
This pull request introduces a change to enable Dynamic Producer Destination functionality in the Azure ServiceBus Binder. This feature allows users to specify message destinations dynamically at runtime by using the AzureHeaders.Name.
##Motivation
Currently, the ServiceBus Binder utilizes the DefaultMessageHandler which supports dynamic destination routing through the AzureHeaders.NAME header. The destination is determined based on the presence of this header in a message (LINK):
private String toDestination(Message<?> message) {
        if (message.getHeaders().containsKey(AzureHeaders.NAME)) {
            return message.getHeaders().get(AzureHeaders.NAME, String.class);
        }

        return this.destination;
    }

However, despite being able to specify a dynamic destination, the message production fails if the DefaultEntityType is not pre-set. This is because the system does not know the entity type (queue or topic) of the destination, and it checks for this setting here (LINK):
@Override
    public ServiceBusSenderAsyncClient createProducer(String name, ServiceBusEntityType entityType) {
        ProducerProperties producerProperties = this.propertiesSupplier.getProperties(name) != null
            ? this.propertiesSupplier.getProperties(name) : new ProducerProperties();
        if (entityType != null) {
            producerProperties.setEntityType(entityType);
        }
        return doCreateProducer(name, producerProperties);
    }

Without a default entity type, the producer creation process fails even if the destination name is dynamically provided.
##Solution
To resolve this issue, I have implemented a change to set the DefaultEntityType accordingly to the entity type specified in the workflow configuration by the user. This ensures that the dynamic destination feature can function correctly and the message to routed properly.
----------------------------------------------------------------//----------------------------------------------------------------
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[X] The pull request does not introduce [breaking changes]
[X] CHANGELOG is updated for new features, bug fixes or other significant changes.
[X] I have read the contribution guidelines.

General Guidelines and Best Practices

[X] Title of the pull request is clear and informative.
[X] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

@Aryelmr please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree company="Solace"

@chenrujun @Netyyyy @saragluna @moarychan
Hello,
Is there something additional I should do to get the PR reviewed or I only get it review after some pipeline is done?
Just trying to understand the process.


The put command sometimes result in broken templates on the server

We use the docker compose setup of the wizard to work on our templates locally as follows:

download the template from a shared server
edit the template files locally
upload to the local server running in Docker
repeat from 2 until we're happy
upload to the shared server

So far we have noticed that dsw-tdk put command sometimes result in broken templates on the server (templates that consistently fail to render any documents) without any changes made to the template files.
Repeat the following to reproduce:

Run dsw-tdk put ....
Attempt to render a document

I have attached logs following the commands related to a broken template.
Docker compose output following dsw-tdk put ...
mongo_1       | 2021-02-11T09:46:08.201+0000 I  NETWORK  [listener] connection accepted from <IP_ADDRESS>:46708 #124 (5 connections now open)
dsw_server_1  | [Info ] [I:------------------------------------] [T:f060a545-9e79-4b5b-8cbd-7ade71153d24] [API         ] 201 Created POST /tokens
dsw_server_1  | [Warn ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:------------------------------------] [API         ] 404 Not Found GET /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:23d61224-693e-4082-befe-acd55e3a41c1] [API         ] 201 Created POST /templates
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:df187f65-bde4-4a86-ae22-8e7301efbc04] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:324b6202-ec1a-4036-86ea-34f0ebdb65d5] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:65b10eba-e1c6-443b-adab-f7ccf5830098] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:37cb8e2f-4cb7-4c9d-80fb-1e0f3364ef5a] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:471ef2f1-c891-402f-bb56-1de2c0928dc9] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:ad754e80-5cff-4de3-be7c-b118959a52d2] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:0a3627f7-78f5-4c9e-a041-e5381a9a88ca] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:d90f636b-1499-4878-ba2c-e28a5709bfe9] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:d6cfd258-28e1-47aa-8bc4-69cb81a0b82f] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/assets
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:99aa5f0d-6839-483f-b904-ea42ba0130a7] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:b9b2c20a-0cf6-468b-807c-b7d77bc45350] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:ad940e34-882c-429b-8dde-20fcfd586147] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:db0dc3f0-6dea-4410-aa5d-4e06f2c3fdcc] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:67e05c8c-9386-4077-8926-9b404446a751] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:7140fa48-93a1-43df-be6f-29a71efffe7c] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:47665f33-00f0-47e8-8977-3f4b7435596e] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:83184dc6-c2ca-4020-83fe-aafd03e6b10c] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:c67d031c-467d-4a51-b191-640a8274095b] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:524d4a0f-49aa-418f-b2c8-52bbcac657c6] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:6eeb04e6-e46f-4a79-ad84-0071809e4ee9] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:abdf9b3d-26f9-4e9c-a1c2-a3890a5d8593] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:abb351be-67af-4653-a421-0a41c7fd17f5] [API         ] 201 Created POST /templates/SciLifeLab:SLL-VR-TEMPLATE:1.0.0/files
mongo_1       | 2021-02-11T09:46:09.980+0000 I  NETWORK  [conn124] end connection <IP_ADDRESS>:46708 (4 connections now open)

Docker compose output following attempt to render a document
mongo_1       | 2021-02-11T09:42:44.958+0000 I  NETWORK  [listener] connection accepted from <IP_ADDRESS>:44842 #92 (5 connections now open)
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:2cd1b575-52f5-40b7-a30d-4225c863c834] [Messaging   ] PublishToQueue: document.generation
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:2cd1b575-52f5-40b7-a30d-4225c863c834] [API         ] 201 Created POST /documents
docworker_1   | 2021-02-11 09:42:44,983 | INFO | worker: Received a job
mongo_1       | 2021-02-11T09:42:44.986+0000 I  NETWORK  [conn90] end connection <IP_ADDRESS>:50100 (4 connections now open)
mongo_1       | 2021-02-11T09:42:44.986+0000 I  NETWORK  [conn89] end connection <IP_ADDRESS>:50098 (3 connections now open)
mongo_1       | 2021-02-11T09:42:44.986+0000 I  NETWORK  [listener] connection accepted from <IP_ADDRESS>:50230 #93 (4 connections now open)
docworker_1   | 2021-02-11 09:42:44,988 | INFO | before: Starting call to 'document_worker.worker.Job.connect_mongo', this is the 1st time calling it.
docworker_1   | 2021-02-11 09:42:44,988 | INFO | worker: Connecting to Mongo DB @ mongo:27017/wizard
mongo_1       | 2021-02-11T09:42:44.989+0000 I  NETWORK  [conn93] received client metadata from <IP_ADDRESS>:50230 conn93: { driver: { name: "PyMongo", version: "3.10.1" }, os: { type: "Linux", name: "Linux", architecture: "x86_64", version: "4.19.121-linuxkit" }, platform: "CPython 3.8.7.final.0" }
mongo_1       | 2021-02-11T09:42:44.991+0000 I  NETWORK  [listener] connection accepted from <IP_ADDRESS>:50232 #94 (5 connections now open)
mongo_1       | 2021-02-11T09:42:44.993+0000 I  NETWORK  [conn94] received client metadata from <IP_ADDRESS>:50232 conn94: { driver: { name: "PyMongo", version: "3.10.1" }, os: { type: "Linux", name: "Linux", architecture: "x86_64", version: "4.19.121-linuxkit" }, platform: "CPython 3.8.7.final.0" }
docworker_1   | 2021-02-11 09:42:44,995 | INFO | worker: Getting the document "152f9fc0-48a3-4065-9957-eb5890f1f2fc" details from Mongo DB
docworker_1   | 2021-02-11 09:42:44,996 | INFO | worker: Job "152f9fc0-48a3-4065-9957-eb5890f1f2fc" details received
docworker_1   | 2021-02-11 09:42:44,996 | INFO | worker: Verifying the received job "152f9fc0-48a3-4065-9957-eb5890f1f2fc" details
docworker_1   | 2021-02-11 09:42:44,996 | INFO | worker: Original state of job is QueuedDocumentState
docworker_1   | 2021-02-11 09:42:44,999 | INFO | templates: Loading SciLifeLab:SLL-VR-TEMPLATE:1.0.0
docworker_1   | 2021-02-11 09:42:44,999 | INFO | templates: Verifying SciLifeLab:SLL-VR-TEMPLATE:1.0.0
docworker_1   | 2021-02-11 09:42:44,999 | INFO | templates: Setting up formats for template SciLifeLab:SLL-VR-TEMPLATE:1.0.0
docworker_1   | 2021-02-11 09:42:44,999 | INFO | templates: Storing files of template SciLifeLab:SLL-VR-TEMPLATE:1.0.0 locally
docworker_1   | 2021-02-11 09:42:45,002 | INFO | templates: Storing assets of template SciLifeLab:SLL-VR-TEMPLATE:1.0.0 locally
docworker_1   | 2021-02-11 09:42:45,002 | INFO | formats: Setting up format "PDF Document" (45469a71-272c-4e3d-833e-cf6492cbcf17)
docworker_1   | 2021-02-11 09:42:45,012 | INFO | worker: Building document by rendering template with context
docworker_1   | 2021-02-11 09:42:45,012 | ERROR | worker: (152f9fc0-48a3-4065-9957-eb5890f1f2fc) Failed to build final document: [TemplateNotFound] parts/macros.html.j2
docworker_1   | 2021-02-11 09:42:45,014 | INFO | worker: (152f9fc0-48a3-4065-9957-eb5890f1f2fc) Set state to ErrorDocumentState
docworker_1   | 2021-02-11 09:42:45,014 | INFO | worker: Job processing finished (ACK sent)

Docker compose output following attempt to delete template
dsw_server_1  | [Info ] [I:3ef96067-8e7a-479e-ae18-1be47f0e2a5d] [T:d4ae7951-60a5-48ca-8c6f-3b8fe5bb4a28] [API         ] 204 No Content DELETE /templates/?organizationId=SciLifeLab&templateId=SLL-VR-TEMPLATE

OK, I was finally able to reproduce it. It is caused by the asynchronous upload... as it call several "edit" on one entity, it may cause some overwrites (the more files you have the more probability that it will happen).
It will be fixed in 2.13.0 (JIRA task: DSW-1043).

v2.13.0 released, please check and re-open if necessary


Need help? Available to help

Hey! I am looking for open source projects to help Ukrainians and I found yours. Great idea! If you need help, just give me a shout 🙏 I am a React Frontend developer (the website is in Vue, I may not be able to help there) but I have done stuff with Express on the backend

Hey there !
I'm glad that you found this project. There are a lot of things you can do to help 👍
I'll add some feature suggestions on the repo in the next minutes. Meanwhile, do not hesitate tu suggest any improvements too 😊


How do you get zoneIDs for a given zone?

I'm unable to find any lists or any easy way to get information on how to actually functionally use this plugin - im very interested in using it, specifically for certain things like not having the right item when entering the TOA loot room, getting itemID is trivial, but how do you get a zoneID?

Unfortunately it is a bit of a pain. The only way I know of is to run runelite on developer mode and use the dev tools to get your region ID while standing in that location.

You can use https://explv.github.io/  with region grid and region labels enabled.


Added channel 4.14 for ODF

Added channel 4.14 for ODF.
*** Tested in a lab and working. ***

Ops... I forgot that... Just added it! Thanks @strangiato !
Done it.

Can you unblock your review @strangiato ? Cheers


Bug: Docker installation - Permission doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS

What are you trying to achieve?
I am installing Saleor by using this giode - https://docs.saleor.io/docs/3.x/setup/docker-compose
Adter this step  => Finally, create an admin account:
docker-compose run --rm api python3 manage.py createsuperuser
After running above step following error is throwing:
RuntimeError: Model class django.contrib.auth.models.Permission doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.
Steps to reproduce the problem
pavan@system-892:~/saleor/saleor-platform$ docker-compose run --rm api python3 manage.py createsuperuser
[+] Running 3/0
 ⠿ Container saleor-platform-db-1      Running                                                                                0.0s
 ⠿ Container saleor-platform-redis-1   Running                                                                                0.0s
 ⠿ Container saleor-platform-jaeger-1  Running                                                                                0.0s
Traceback (most recent call last):
  File "/app/manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 413, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 354, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.9/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 79, in execute
    return super().execute(*args, **options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 398, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.9/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 100, in handle
    default_username = get_default_username(database=database)
  File "/usr/local/lib/python3.9/site-packages/django/contrib/auth/management/__init__.py", line 115, in get_default_username
    from django.contrib.auth import models as auth_app
  File "/usr/local/lib/python3.9/site-packages/django/contrib/auth/models.py", line 35, in <module>
    class Permission(models.Model):
  File "/usr/local/lib/python3.9/site-packages/django/db/models/base.py", line 113, in __new__
    raise RuntimeError(
RuntimeError: Model class django.contrib.auth.models.Permission doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.
pavan@system-892:~/saleor/saleor-platform$

What did you expect to happen?
It should have created a new super user and should have allowed to login as super user in the dashboard.
Logs
No response
Environment
Saleor version: …
OS and version: Docker based installation - https://docs.saleor.io/docs/3.x/setup/docker-compose

I have the same problem, I am using docker to generate the images and it does not allow me to create the super user with the command specified in the documentation.

Will be fixed by https://github.com/saleor/saleor/pull/11810

I still get this error with the latest docker image. Am I missing something?

Hello @VictorHurtado @mistrypavan 👋
Can you please confirm if the PR mentioned by @akhial fixed it for you?


Issues with strategicMergePatches/jsonPatches on charts rendering strings with golang template delimiters

Hi,
Using strategicMergePatches or jsonPatches on releases based on charts rendering strings with golang template delimiters, like the prometheus-operator chart is not working.
After analysing, the problem seems to be the additional helm run (template, diff or upgrade) on the modified patched release. This temporary patched chart definition has a generated 'templates/helmx.all.yaml' file with all patched manifests. If there are golang template delimiters in them, helm tries to interpolate them, resulting in missing variables as these variables are not intended to be used by helm, but by the underlying application.
I did some tests and could find possible workaround to this issue:

Create the generated helmx.all.yaml in the root folder of the temporary chart definition, not in the templates folder (one level up)
Add a new file in the template folder, for intstance 'get.helmx.all.yaml', with following content:

{{ .Files.Get "helmx.all.yaml" }}

This makes helm not interpolating the manifests and will enable the patching of upstream charts rendering strings with golang template delimiters, like the prometheus-operator chart.
I would love to make a PR myself, but unfortunately, I'm not used to code in golang.
Cheers
Marc

@msutter Hey! Thanks for your detailed report, and sharing the Files.Get idea`. I'll try fixing it that way.

This is going to be fixed via #1363


docs(SlashCommandMixin): document .children

Summary
Closes #798
This documents the SlashCommandMixin.children property.
Checklist

[x] If code changes were made then they have been tested.

[x] I have updated the documentation to reflect the changes.
[ ] I have run task pyright and fixed the relevant issues.

[x] This PR fixes an issue.
[ ] This PR adds something new (e.g. new method or parameters).
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[ ] This PR is not a code change (e.g. documentation, README, ...)

I have absolutely no clue as to why https://github.com/nextcord/nextcord/pull/851/commits/b3691b3bd55c1397c81f90068a5af580ecbeff89 is here 💀

Since SlashCommandMixin.children is now read-only, you should update the rest of the code to reflect these changes

Fixed in https://github.com/nextcord/nextcord/pull/851/commits/7dedb6cf295aa5aa08c899ed6db9ba57216785c0 , checked with everything that previously used children to see if they should use _children or not, they don't. Except this one 🙂


[Feature]What about MeshGraphormer Hand Refiner for SDXL

any plan on this?

@vvip2u I'm not the author of HandRefiner but just someone port that to Comfy. Make an issue here instead