Bilateral link between a resource and a scene corrupt the resource file

Tested versions
I don't know about this. I belive it is present starting with Godot 4.0. Before there weren't resources to test.
Tested version Godot 4.3
System information
Godot v4.3.stable - Ubuntu 24.04.1 LTS 24.04 - X11 - GLES3 (Compatibility) - NVIDIA GeForce GTX 1060 3GB (nvidia; 535.183.01) - AMD Ryzen 9 3900X 12-Core Processor (24 Threads)
Issue description
Bilateral link between a resource and a scene is present and scene is open, if Godot is closed and then the project is reopened it corrupts the resource file. After that the scene with corrupted resource file can't be opened, the only way to deal with it is to delete and create another resource. But then again, once scene is open and editor and Godot editor is closed and reopened, the issue have chance to appear again.
I understand that it is kinda bad link, when both files link each other, but it doesn't affect running performance, and since that I belive it should be allowed, and do not cause such issues
Steps to reproduce
Current project already contain corrupted file. If you want to test the process, just delete the resource tres file, then create another one, give it link to another scene, and that scene should have link to the resource. Then when Bug scene is open in editor, close it, and then reopen the project. There is a great chance that the resource will be corrupted
Minimal reproduction project (MRP)
Bug report.zip

This is a known limitation, see here, here, here, and here
Please see this proposal for this topic, but this is a known and documented limitation, so closing, but thank you for your report:

https://github.com/godotengine/godot-proposals/issues/7363


Improve RangeSet initialization performance

When initializing a range set with a group of overlapping, identical, or empty ranges, the initializer can exhibit poor performance due to removing the unneeded ranges during processing. This change uses a partitioning scheme instead, only removing the unnecessary ranges at the end of initialization.

@swift-ci Please smoke test

@swift-ci Please test

@swift-ci Please test


Overwrite creates new file

version: delta v0.6.3
environment: cloud, azure
mode overwrite used.
no partition by option used
I see new file being created each time after write:
1-...
2-...
...
6-...
I would expect same file being overwritten so I would expect to see:
1-...
only.
import pyarrow as pa
from deltalake.writer import write_deltalake
storage_options = {   "AZURE_STORAGE_ACCOUNT_NAME": account_name,    "AZURE_STORAGE_ACCOUNT_KEY": account_key, }
table_path =<EMAIL_ADDRESS>dt = DeltaTable(table_path, storage_options=storage_options)
tb = pa.Table.from_pandas(df, preserve_index=False)
write_deltalake(table_or_uri=dt, data=tb, mode="overwrite")

delta_table.vacuum(retention_hours=0, enforce_retention_duration=False, dry_run=False)
I have to perform vacuum after all in order to delete non latest version files.

delta_table.vacuum(retention_hours=0, enforce_retention_duration=False, dry_run=False)
I have to perform vacuum after all in order to delete non latest version files.

Hi @0xdarkman, this is intentional and part of the Delta protocol. ACID guarantees and time travel would not work without it.


wrong options in Q.98

I guess the fix here is not adding a new option, but to fix
const getUser = user => { name: user.name, age: user.age }

to become
const getUser = user => ({ name: user.name, age: user.age })


Title large sporadic rendering on scroll to top - iOS 12.2, Cordova

Framework7 version: latest 4.2.2
Platform and Target: iOS 12.2, Cordova iOS 5.0
Live Link or JSFiddle: https://youtu.be/91z1wBgVGEM

Describe the bug
In Cordova app, the header title large will not render until after bounce animation finishes when scrolling back to the top of the app body.
https://youtu.be/91z1wBgVGEM
To Reproduce
Steps to reproduce the behavior:

Deploy Framework7 kitchen sink app to Cordova app
Scroll half way down on the main page of the kitchen sink app
Forcefully scroll back up to the top
Observe janky rendering

Expected behaviour
Title renders immediately on scroll into view instead of waiting till after page bounce
Actual Behavior
Title renders only after page bounce animation finishes when scrolling to the top of the page
Screenshots
https://youtu.be/91z1wBgVGEM

And you of course use WKWebView ?

I had this problem with UIWebview and Simulator. I did not have this problem changing to WKWebview and deploying to actual device.

Didn't realize WKWebView was needed for this! After messing around with WKWebView on Cordova 4.5.5, was able to clear up this performance issue. Thank you.


Created and mocked the Gps interface

Built the gps interface and its mocking infrastructure

New line at bottom of the file was a misunderstanding. All files added to this commit do have a new line at the bottom.


Namespace cookie / localstorage

There is a conflict if we use multiple supabase projects in the same website. This is because we use the same key to read from localstorage / cookie. We will need to name space the token per project.

Merging with https://github.com/supabase/gotrue-js/issues/213

I think this is a separate issue from https://github.com/supabase/gotrue-js/issues/213.


Feature Requests

Can the timers be turned off to do infinite play on the slideshows?

Not today. See here: #190

Is there any way to have the app restart and play the slideshow every 11 hours or so to address the limit from google?
Sent from my iPhone
On Jul 21, 2019, at 10:42 AM, Chris Taylor <notifications<EMAIL_ADDRESS>wrote:
Not today. See here: #190https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchtaylo2%2FRoku-GooglePhotos%2Fissues%2F190&data=02|01||2fbbe71427544f2dbd8808d70df20c65|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636993205543132128&sdata=ofZ1jfgMymTWG4pMDHTu5L6gQvQrqnt44%2BFB8v7P%2F8E%3D&reserved=0
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchtaylo2%2FRoku-GooglePhotos%2Fissues%2F236%3Femail_source%3Dnotifications%26email_token%3DAMT2EFBNY6LRA2VCFA7R553QAR7WTA5CNFSM4IDYRDPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2OGCKA%23issuecomment-513564968&data=02|01||2fbbe71427544f2dbd8808d70df20c65|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636993205543142145&sdata=YcgdA1xRerZ3I%2BiQEoVIiUJW2ux6KTW%2BTvBUR7DPAUc%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMT2EFHQT2YQJJXZVN5ELJLQAR7WTANCNFSM4IDYRDPA&data=02|01||2fbbe71427544f2dbd8808d70df20c65|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636993205543152150&sdata=yW4CAbF4xYpXTDb5QqJbNq5hH%2Bvv%2Femo4C%2BoXM%2FxGLM%3D&reserved=0.


Update base64 from ^0.20 to ^0.21

Description
Update base64 from ^0.20 to ^0.21
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #105 (5ced01a) into main (909b1f9) will decrease coverage by 4.65%.
The diff coverage is 0.00%.

:exclamation: Current head 5ced01a differs from pull request most recent head 113d314. Consider uploading reports for the commit 113d314 to get more accurate results

@@            Coverage Diff             @@
##             main     #105      +/-   ##
==========================================
- Coverage   42.28%   37.63%   -4.66%
==========================================
  Files          50       50
  Lines       28086    28085       -1
==========================================
- Hits        11877    10569    -1308
- Misses      16209    17516    +1307

Flag
Coverage Δ

integration
37.63% <0.00%> (-4.66%)
:arrow_down:

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

Impacted Files
Coverage Δ

opensearch/src/http/transport.rs
42.35% <0.00%> (-7.26%)
:arrow_down:

opensearch/src/indices.rs
38.98% <0.00%> (-8.90%)
:arrow_down:

yaml_test_runner/tests/common/client.rs
87.87% <0.00%> (-6.07%)
:arrow_down:

opensearch/src/root/mod.rs
31.02% <0.00%> (-5.65%)
:arrow_down:

opensearch/src/cat.rs
40.41% <0.00%> (-5.35%)
:arrow_down:

opensearch/src/cluster.rs
38.59% <0.00%> (-3.91%)
:arrow_down:

yaml_test_runner/src/step/skip.rs
85.91% <0.00%> (-2.82%)
:arrow_down:

yaml_test_runner/src/skip.rs
92.50% <0.00%> (-2.50%)
:arrow_down:

opensearch/src/http/response.rs
16.18% <0.00%> (-2.32%)
:arrow_down:

... and 4 more

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


[Docs] Update Ad Reporting Info about Google Ads API and Deprecated AdWords API

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the issue
This section (https://github.com/fivetran/dbt_ad_reporting/tree/v0.7.0/#google-ads-and-adwords-api-configuration) needs updated to reflect the changes to Google's APIs.
Relevant error log or model output
N/A

Expected behavior
Google Ads API is the only API to worry about.
dbt Project configurations
N/A
Package versions
N/A
What database are you using dbt with?
other (mention it in "Additional Context")
dbt Version
N/A
Additional Context
https://fivetran.slack.com/archives/CAGK0BU0Z/p1653080137055409
Are you willing to open a PR to help address this issue?

[X] Yes.
[ ] Yes, but I will need assistance and will schedule time during our office hours for guidance
[ ] No.

The recent release of v0.8.0 of this package addresses this issue.


Fix resize crash

Crashes when resizing all the way down to 0 then trying to increase it back out
There's a slight chance that it doesn't crash, I don't quite understand it, thought maybe its the surface sizes being odd integers for the first call to SetSurfaceSize after 0 is set

LGTM, thanks.


How is the progress?

Hey 👋.
This isn't really an issue, but I wasn't sure where else to put this, as this seems to be the only platform for communication. I just wanted to know how the progress is going, and whether the end-of-october release target for iroh (and documentation) is still more or less valid?
:)

👋 @slavuwu! Thanks for asking ☺. We are still planning on an October release, in the next day or so in fact. I’ll close this issue once we’ve cut the release to keep you in the loop.
As for a discussion platform, I’m thinking we may use the discussion feature here on GitHub. I’ll be spending time bootstrapping discussion over there once we have a release up, so feel free to keep the conversation going over there

@b5 Thanks for the reply. Glad everything is going as planned. I'm very excited for the release! 😁

Hey @slavuwu! We cut the release! here's a video of us pushing the release button on stage: https://youtu.be/HRYREdsLt5k?t=133 installation instructions are available over at https://iroh.computer/install


ERROR thaliPeerPoolDefault: Got error: 'Error: Could not establish TCP connection'

I've found a bug in vNext_aaladev_417_812_1034: jx runCoordinatedTests.js will be finished successfully, but we can see an exception ERROR thaliPeerPoolDefault: Got error: 'Error: Could not establish TCP connection' after all tests finished.
It looks like some test didn't clear its resources after teardown. We need to investigate it.

@andrew-aladev I'm fairly sure you have solved this one but I thought I would confirm.

No repro


Moonstream faucet - Polygon mumbai testnet

We need a faucet page for the Mumbai testnet where people can go to get MNSTR token minted to their addresses.
On the same site, we can also send MATIC to their addresses (if available to us) so that they never run into an issue of not having enough MATIC to pay gas.

@Yhtiyar implemented this change.
@kompotkot will set up the infrastructure (static hosting on S3).


VS Code syntax highlighting is disabled after event declaration

Problem
When declaring events, the next few lines after the event declaration do not get highlighted correctly.
Steps to Reproduce

Copy this contract:

pub contract Test {

    pub event Event()

    pub event Second()

    pub var field: Int

    pub fun changeVar() {
        self.field = 1
    }
}

See that the fields after Event are not highlighted properly.

@joshuahannan transferred this issue to the VS Code extension repo.

Example of the bug:

@turbolent @joshuahannan is this bug still present?

@turbolent @joshuahannan is this bug still present?

Here's another example


dataset configuration for no-reference dataset

Thanks for you great work,
I was just wondering how the dataset configuration should be for
datasets without any references, (like urban100).
Currently, I'm simply forwarding a directory with downscaled version of inputs, as in the paper.
But I'm not confident about this since I'm getting SR images full of artifacts.

dataroot_in: /Dataset1
dataroot_ref: /Dataset1_downscaledx4
ann_file <-- commented out

Thanks for your interest in our work!
For datasets without any references, we still need the ann_file. You may construct the ann_files like this. For each line, the first one is the original image name, the second one is the downsampled image name.
We also attached our results in Google Drive. You may have a check. Thanks.


Vocabs not tagged as a "Platform" vocab appears under "Platform"

See screenshot where under the "Platform" Wildcard tab we have 2 vocabs with a match: One is a platform vocab but the other was not tagged as belonging to the platform graph so I was not expecting to see it there. Is it because this has not yet fully implemented?

Do you recall which record this was for?

Same as the other: ICOS Data Portal (2020) from NO-SOOP-Nuka Arctica, 2017-07-06–2017-


New theme for Django Admin

Hi there! 👋
Here's a new theme for the Django web framework's built-in admin:
https://github.com/sjbitcode/django-admin-dracula
The Django admin already comes with a default light and dark theme, so I made "dracula" versions for both! 🦇
Thank you!

Hey, that's very cool! ✨
I just sent you an invitation to join the organization.
I also cloned your repository for Dracula's organization, so you can go ahead and delete or archive yours:

Your repository.
New repository.

Thanks for building this! 🎉


Deal With Keywords That Have Commas and Quotes

It appears like quotes and commas in keyword definitions are throwing off the seeding code I wrote. "Ray A. and Robert L. Kroc Lectureship" is a good fund to look at in order to see multiple keywords and one that has quotes involved. I don't know much more at this time.
Required
Describe the bug
Keywords don't get properly imported if they are encapsulated in quotes and have commas within the keyword label.
To Reproduce
Steps to reproduce the behavior:

Install a new site with drush si --existing-config.
drush en cua_seed_content -y module.
See errors in terminal output during seeding process.
Check for missing keywords on "Ray A. and Robert L. Kroc Lectureship". Only two of three keywords get properly imported.

Expected behavior
All keywords should be included in seeded content.

this should have been closed by stalebot but was not for some reason.


Cherry-picking translations

Summary
Cherry-picking translations from https://github.com/mattermost/mattermost-mobile/pull/7859
Release Note
NONE

Hello @ctlaltdieliet,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Adding Daniel here to help merge this as I don't have permissions.


fix: returning error in useExecute

Returning error in useExecute

:tada: This PR is included in version 1.8.1-stage.1 :tada:
The release is available on:

npm package (@stage dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.8.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


feat: support PEM format for Kafka cluster SSL client certificates/key

What is currently missing?
Currently Kafka cluster SSL connectivity requires Java-specific, file-based, password-protected key stores/trust stores. PEM format is not supported. Related GitHub discussion: https://github.com/aiven/klaw/discussions/166
How could this be improved?
Kafka clients can be configured to use PEM SSL certificates/keys. AFAIK Aiven console also provides Kafka SSL certificates/keys in PEM format out of the box.
Hence it would be helpful to (optionally) allow cluster SSL client certificate/key and CA certificate chain to be configured in PEM format, which can also be readily injected through Spring config properties (as Strings). This might also help us externalize the cluster SSL config, e.g. when running Klaw in-container, where mounting SSL key files may not be trivial (e.g. in AWS ECS).
In an AWS environment, one option for loading the Kafka SSL properties/secrets at runtime, is to use e.g. Spring Cloud AWS (secrets manager or parameter store). See here for more details.
Security consideration: compare in-memory passwordless PEM private key (loaded at runtime from a secure vault such as AWS Secrets Manager) vs. filesystem-based, password-protected private key + in-memory password (loaded from a secure vault, or decrypted, at runtime).
Is this a feature you would work on yourself?

[ ] I plan to open a pull request for this feature

@jpalomaki this issue is now closed after merging the relevant changes from #511 PR.
Ex klaw config which now works with pem certs as strings.
dev1.kafkassl.keystore.type=PEM
dev1.kafkassl.keystore.certificate.chain=-----BEGIN CERTIFICATE-----
..
-----END CERTIFICATE-----
dev1.kafkassl.keystore.key=-----BEGIN PRIVATE KEY-----
..
-----END PRIVATE KEY-----


feature(jumplist): stack-style jumplist when setpcmark

Similar with JUMPLIST_ROTATE except that the entrys from last used entry to the top will be delete, but not rotating.
JUMPLIST_ROTATE is prior to JUMPLIST_STACK_STYLE

The problem is that this is a compile time choice.  We should either remove this, and make a patch available for those who want it, or make it a runtime option.
The problem with making this a runtime option is that plugins might have to know about the option and handle the different behavior.  Or change the option and restore it later.  It's going to be obscure, thus I tend to think we should not add this option.

OK, fine.
By the way , I would like to specify the problem which drives me to make such option and ask for some advice.
It's when I'm trying to understand some codebase with vim using  and  to jump back and forward. However, I found that the jumplist produced by the default behavior of  and  is not so consistent with the code path I would like to understand. Here is an example, suppose we have such a file to understand:
package main

import "fmt"

func main() {
	fmt.Println("vim-go")
	hello_world()
	final_answer()
}

func hello_world() {
	hello()
	world()
}

func hello() {
	...
}

func world() {
	...
}

func final_answer() {
	final()
	answer()
}

func final() {
	...
}

func answer() {
	...
}

The call graph is like this:

And I would like to understand the whole file from the main function. And the jumplist  with  and  I would like to have is like this:

main -> 2. the call position of hello_world in main -> 3. the definition of hello_world -> 4. the call position of hello -> 5. the definition of hello -> 6. the call position of hello -> 7. the call position of world -> 8. the definition of world -> 9. the call position of world -> 10. the call position of hello_world ...

As I think such jumplist is more consistent with the call graph of the code.
But when I found that the actual behavior of  and  in vim will produce such jumplist:

main -> 2. the call position of hello_world in main -> 3. the definition of hello_world -> 4. the call position of hello -> 5. the definition of hello -> 6. the call position of hello -> 7. the call position of world -> 8. the definition of world

So far it's the same with the jumplist I want. But after I finish checking the definition of world and use  to jump back, and I will jump to the definition of hello. It confuse me when the call graph is so deep and I need jump between differen call path in a function. And finally, I always found that I'm lost in the jumplist, so I have to clear the jumplist and read it again.
With a figure to specify the problem:

The red jumplist is what I want, and the blue one is what i get with the default behavor of  and .
With the red one, I can jump back to the call point of world in hello_world and the call point of hello_world in main quicklly, so that I can start to check the code of final_answer after I finish the checking of hello_world.
While with the blue one, after I finish the checking of the function world, I need to jump back to all the jump point to the call point hello_world(the blue 5, 6, 7 in the figure) to start the  checking of the final_answer in the main function.
And after I search for any solution to this problem, I got nothing. So I dive into the source code, complete my idea  make such a pr.
So, any way to  get the red jumplist I want in the figure, without change the source code like this pr? some plugin or ?
Thanks for your time to reading my problem.

@WinChua  In case you are still looking for an answer: I think your second post should go to a site like https://vi.stackexchange.com/
And do you know vim's tag stack and CTRL-T to go upwards within the tag stack (red path in your figure)?
:h tagstack:
...
You can jump to previously used tags with several commands.  Some examples:

	":pop" or CTRL-T	to position before previous tag
	{count}CTRL-T		to position before {count} older tag
	":tag"			to newer tag
	":0tag"			to last used tag

The most obvious way to use this is while browsing through the call graph of
a program.  Consider the following call graph:

	main  --->  FuncA  --->  FuncC
	      --->  FuncB

(Explanation: main calls FuncA and FuncB; FuncA calls FuncC).
You can get from main to FuncA by using CTRL-] on the call to FuncA.  Then
you can CTRL-] to get to FuncC.  If you now want to go back to main you can
use CTRL-T twice.  Then you can CTRL-] to FuncB.

@WinChua  In case you are still looking for an answer: I think your second post should go to a site like https://vi.stackexchange.com/
And do you know vim's tag stack and CTRL-T to go upwards within the tag stack (red path in your figure)?
:h tagstack:
...
You can jump to previously used tags with several commands.  Some examples:

	":pop" or CTRL-T	to position before previous tag
	{count}CTRL-T		to position before {count} older tag
	":tag"			to newer tag
	":0tag"			to last used tag

The most obvious way to use this is while browsing through the call graph of
a program.  Consider the following call graph:

	main  --->  FuncA  --->  FuncC
	      --->  FuncB

(Explanation: main calls FuncA and FuncB; FuncA calls FuncC).
You can get from main to FuncA by using CTRL-] on the call to FuncA.  Then
you can CTRL-] to get to FuncC.  If you now want to go back to main you can
use CTRL-T twice.  Then you can CTRL-] to FuncB.

We have ':set jumpoptions=stack'  now, so I think this can be closed.


[BUG] Milestone 3 breaks Environment API client code generation

Describe the bug
With milestone 2 I was able to generate a C# client SDK for Discovery, Shell repository, Submodel repository and Environment APIs using Kiota. With Milestone 3 I can no longer generate a client for the Environment API. The others work fine.

Here's the trace log from running Kiota on my running instance of basyx-environment. It gives a vague error at the end and then doesn't output anything.
Trace: KiotaBuilder configuration: {"Generation":{"ShouldGetApiManifest":false,"SkipGeneration":false,"Operation":null,"OpenAPIFilePath":"http://localhost:8081/v3/api-docs","ApiManifestPath":"C:\\REDACTEDBaSyx\\apimanifest.json","OutputPath":"C:\\REDACTEDBaSyx\\.\\Generated","ClientClassName":"EnvironmentClient","ClientNamespaceName":"REDACTEDBaSyx","NamespaceNameSeparator":".","ModelsNamespaceName":"REDACTEDBaSyx.models","Language":0,"PluginTypes":[],"ApiRootUrl":null,"UsesBackingStore":false,"ExcludeBackwardCompatible":true,"IncludeBackwardCompatible":false,"IncludeAdditionalData":true,"Serializers":["Microsoft.Kiota.Serialization.Json.JsonSerializationWriterFactory","Microsoft.Kiota.Serialization.Text.TextSerializationWriterFactory","Microsoft.Kiota.Serialization.Form.FormSerializationWriterFactory","Microsoft.Kiota.Serialization.Multipart.MultipartSerializationWriterFactory"],"Deserializers":["Microsoft.Kiota.Serialization.Json.JsonParseNodeFactory","Microsoft.Kiota.Serialization.Text.TextParseNodeFactory","Microsoft.Kiota.Serialization.Form.FormParseNodeFactory"],"ShouldWriteNamespaceIndices":false,"ShouldWriteBarrelsIfClassExists":false,"CleanOutput":false,"StructuredMimeTypes":["application/json","text/plain;q=0.9","application/x-www-form-urlencoded;q=0.2","multipart/form-data;q=0.1"],"IncludePatterns":[],"ExcludePatterns":[],"PatternsOverride":[],"ClearCache":false,"DisabledValidationRules":[],"MaxDegreeOfParallelism":-1,"IsPluginConfiguration":false,"DisableSSLValidation":false},"Search":{"APIsGuruListUrl":"https://raw.githubusercontent.com/APIs-guru/openapi-directory/gh-pages/v2/list.json","GitHub":{"AppId":"Iv1.9ed2bcb878c90617","ApiBaseUrl":"https://api.github.com","BlockListUrl":"https://raw.githubusercontent.com/microsoft/kiota/main/resources/index-block-list.yml","AppManagement":"https://aka.ms/kiota/install/github"},"ClearCache":false},"Download":{"OutputPath":"./output/result.json","CleanOutput":false,"DisableSSLValidation":false,"ClearCache":false},"Languages":{"CLI":{"MaturityLevel":1,"Dependencies":[{"Name":"Microsoft.Kiota.Abstractions","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Http.HttpClientLibrary","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Serialization.Form","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Serialization.Json","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Authentication.Azure","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Serialization.Text","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Cli.Commons","Version":"1.1.2"}],"DependencyInstallCommand":"dotnet add package {0} --version {1}","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"CSharp":{"MaturityLevel":2,"Dependencies":[{"Name":"Microsoft.Kiota.Abstractions","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Http.HttpClientLibrary","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Serialization.Form","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Serialization.Json","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Authentication.Azure","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Serialization.Text","Version":"1.11.0"},{"Name":"Microsoft.Kiota.Serialization.Multipart","Version":"1.11.0"}],"DependencyInstallCommand":"dotnet add package {0} --version {1}","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"Go":{"MaturityLevel":2,"Dependencies":[{"Name":"github.com/microsoft/kiota-abstractions-go","Version":"v1.6.1"},{"Name":"github.com/microsoft/kiota-http-go","Version":"v1.4.3"},{"Name":"github.com/microsoft/kiota-serialization-form-go","Version":"v1.0.0"},{"Name":"github.com/microsoft/kiota-serialization-json-go","Version":"v1.0.7"},{"Name":"github.com/microsoft/kiota-authentication-azure-go","Version":"v1.1.0"},{"Name":"github.com/microsoft/kiota-serialization-text-go","Version":"v1.0.0"},{"Name":"github.com/microsoft/kiota-serialization-multipart-go","Version":"v1.0.0"}],"DependencyInstallCommand":"go get {0}@{1}","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"Java":{"MaturityLevel":2,"Dependencies":[{"Name":"com.microsoft.kiota:microsoft-kiota-abstractions","Version":"1.2.0"},{"Name":"com.microsoft.kiota:microsoft-kiota-http-okHttp","Version":"1.2.0"},{"Name":"com.microsoft.kiota:microsoft-kiota-serialization-form","Version":"1.2.0"},{"Name":"com.microsoft.kiota:microsoft-kiota-serialization-json","Version":"1.2.0"},{"Name":"com.microsoft.kiota:microsoft-kiota-authentication-azure","Version":"1.2.0"},{"Name":"com.microsoft.kiota:microsoft-kiota-serialization-text","Version":"1.2.0"},{"Name":"com.microsoft.kiota:microsoft-kiota-serialization-multipart","Version":"1.2.0"},{"Name":"jakarta.annotation:jakarta.annotation-api","Version":"3.0.0"}],"DependencyInstallCommand":"{0}:{1}","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"PHP":{"MaturityLevel":2,"Dependencies":[{"Name":"microsoft/kiota-abstractions","Version":"1.4.0"},{"Name":"microsoft/kiota-http-guzzle","Version":"1.3.0"},{"Name":"microsoft/kiota-serialization-json","Version":"1.3.0"},{"Name":"microsoft/kiota-authentication-phpleague","Version":"1.2.0"},{"Name":"microsoft/kiota-serialization-text","Version":"1.1.0"},{"Name":"microsoft/kiota-serialization-multipart","Version":"1.0.0"},{"Name":"microsoft/kiota-serialization-form","Version":"1.1.1"}],"DependencyInstallCommand":"composer require {0}:{1}","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"Python":{"MaturityLevel":2,"Dependencies":[{"Name":"microsoft-kiota-abstractions","Version":"1.3.3"},{"Name":"microsoft-kiota-http","Version":"1.3.2"},{"Name":"microsoft-kiota-serialization-json","Version":"1.3.0"},{"Name":"microsoft-kiota-authentication-azure","Version":"1.0.0"},{"Name":"microsoft-kiota-serialization-text","Version":"1.0.0"},{"Name":"microsoft-kiota-serialization-form","Version":"0.1.0"},{"Name":"microsoft-kiota-serialization-multipart","Version":"0.1.0"}],"DependencyInstallCommand":"pip install {0}=={1}","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"Ruby":{"MaturityLevel":0,"Dependencies":[{"Name":"microsoft_kiota_abstractions","Version":"0.14.4"},{"Name":"microsoft_kiota_faraday","Version":"0.15.0"},{"Name":"microsoft_kiota_serialization_json","Version":"0.9.1"},{"Name":"microsoft_kiota_authentication_oauth","Version":"0.8.0"}],"DependencyInstallCommand":"gem install \u0022{0}\u0022 -v \u0022{1}\u0022","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"Swift":{"MaturityLevel":0,"Dependencies":[],"DependencyInstallCommand":"","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]},"TypeScript":{"MaturityLevel":1,"Dependencies":[{"Name":"@microsoft/kiota-abstractions","Version":"1.0.0-preview.59"},{"Name":"@microsoft/kiota-http-fetchlibrary","Version":"1.0.0-preview.58"},{"Name":"@microsoft/kiota-serialization-form","Version":"1.0.0-preview.48"},{"Name":"@microsoft/kiota-serialization-json","Version":"1.0.0-preview.59"},{"Name":"@microsoft/kiota-authentication-azure","Version":"1.0.0-preview.54"},{"Name":"@microsoft/kiota-serialization-text","Version":"1.0.0-preview.56"},{"Name":"@microsoft/kiota-serialization-multipart","Version":"1.0.0-preview.37"}],"DependencyInstallCommand":"npm install {0}@{1} -SE","ClientClassName":"","ClientNamespaceName":"","StructuredMimeTypes":[]}},"Update":{"OrgName":"microsoft","RepoName":"kiota","Disabled":false}}
Debug: KiotaBuilder kiota version 1.17.0
Debug: KiotaBuilder cache file C:\Users\REDACTED\AppData\Local\Temp\kiota\cache\generation\8BDA0BAAA35A629EE553DB234EBDAAD707BD8986787C78156DEECE5B8B8F10C1\api-docs not found, downloading from http://localhost:8081/v3/api-docs
Information: KiotaBuilder skipping cache write for URI http://localhost:8081/v3/api-docs as it is a loopback address
Information: KiotaBuilder loaded description from remote source
Trace: KiotaBuilder 60ms: Read OpenAPI file http://localhost:8081/v3/api-docs
Debug: KiotaBuilder step 1 - reading the stream - took 00:00:00.0640603
Trace: KiotaBuilder Parsing OpenAPI file
Warning: KiotaBuilder OpenAPI warning: #/paths/~1submodels~1{submodelIdentifier}~1submodel-elements~1{idShortPath}/post - The operation describes multiple response schemas that are divergent. Only the schema of the lowest success status code will be used.
Warning: KiotaBuilder OpenAPI warning: #/paths/~1submodels/post - The operation describes multiple response schemas that are divergent. Only the schema of the lowest success status code will be used.
Warning: KiotaBuilder OpenAPI warning: #/paths/~1submodels~1{submodelIdentifier}~1submodel-elements/post - The operation describes multiple response schemas that are divergent. Only the schema of the lowest success status code will be used.
Warning: KiotaBuilder OpenAPI warning: #/paths/~1shells/post - The operation describes multiple response schemas that are divergent. Only the schema of the lowest success status code will be used.
Warning: KiotaBuilder OpenAPI warning: #/paths/~1shells~1{aasIdentifier}~1submodel-refs/post - The operation describes multiple response schemas that are divergent. Only the schema of the lowest success status code will be used.
Warning: KiotaBuilder OpenAPI warning: #/paths/~1concept-descriptions/post - The operation describes multiple response schemas that are divergent. Only the schema of the lowest success status code will be used.
Trace: KiotaBuilder 122ms: Parsed OpenAPI successfully. 20 paths found.
Debug: KiotaBuilder step 2 - parsing the document - took 00:00:00.1244297
Debug: KiotaBuilder step 3 - updating generation configuration from kiota extension - took 00:00:00.0000934
Debug: KiotaBuilder step 4 - filtering API paths with patterns - took 00:00:00.0048009
Information: KiotaBuilder Client root URL set to http://localhost:8081
Debug: KiotaBuilder step 5 - checking whether the output should be updated - took 00:00:00.0166522
Trace: KiotaBuilder 6ms: Created UriSpace tree
Debug: KiotaBuilder step 6 - create uri space - took 00:00:00.0069462
Debug: KiotaBuilder InitializeInheritanceIndex 00:00:00.0035151
Trace: KiotaBuilder Creating class EnvironmentClient
Trace: KiotaBuilder Creating property submodels of submodelsRequestBuilder
Trace: KiotaBuilder Creating property shells of shellsRequestBuilder
Trace: KiotaBuilder Creating property conceptDescriptions of conceptDescriptionsRequestBuilder
Trace: KiotaBuilder Creating property upload of uploadRequestBuilder
Trace: KiotaBuilder Creating property serialization of serializationRequestBuilder
Trace: KiotaBuilder Creating property description of descriptionRequestBuilder
Trace: KiotaBuilder Creating class serializationRequestBuilder
Trace: KiotaBuilder Creating class conceptDescriptionsRequestBuilder
Trace: KiotaBuilder Creating class descriptionRequestBuilder
Trace: KiotaBuilder Creating class shellsRequestBuilder
Trace: KiotaBuilder Creating class submodelsRequestBuilder
Trace: KiotaBuilder Creating class uploadRequestBuilder
Trace: KiotaBuilder Creating indexer WithCdIdentifier-indexer
Trace: KiotaBuilder Creating indexer WithAasIdentifier-indexer
Trace: KiotaBuilder Creating indexer WithSubmodelIdentifier-indexer
Warning: KiotaBuilder Could not create error type for 400 in uploadEnvironment
Warning: KiotaBuilder Could not create error type for 500 in uploadEnvironment
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Post of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Post of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPostRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPostRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class WithAasIdentifierItemRequestBuilder
Trace: KiotaBuilder Creating property assetInformation of assetInformationRequestBuilder
Trace: KiotaBuilder Creating property submodelRefs of submodelRefsRequestBuilder
Warning: KiotaBuilder Discriminator Capability is not inherited from DataElement.
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Put of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPutRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Delete of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToDeleteRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class assetInformationRequestBuilder
Trace: KiotaBuilder Creating property thumbnail of thumbnailRequestBuilder
Trace: KiotaBuilder Creating class submodelRefsRequestBuilder
Trace: KiotaBuilder Creating indexer WithSubmodelIdentifier-indexer
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Put of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPutRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class thumbnailRequestBuilder
Warning: KiotaBuilder Discriminator Capability is not inherited from SubmodelElement.
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Warning: KiotaBuilder Discriminator DataElement is not inherited from SubmodelElement.
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Post of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPostRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class WithSubmodelIdentifierItemRequestBuilder
Trace: KiotaBuilder Creating method Put of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPutRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Delete of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToDeleteRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Delete of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToDeleteRequestInformation of Kiota.Builder.CodeDOM.CodeType
Warning: KiotaBuilder Discriminator Capability is not inherited from EventElement.
Warning: KiotaBuilder Discriminator DataElement is not inherited from EventElement.
Warning: KiotaBuilder Discriminator SubmodelElement is not inherited from EventElement.
Warning: KiotaBuilder Discriminator EventElement is not inherited from SubmodelElement.
Warning: KiotaBuilder Discriminator EventElement is not inherited from DataElement.
Warning: KiotaBuilder Discriminator SubmodelElement is not inherited from DataElement.
Warning: KiotaBuilder Discriminator DataElement is not inherited from Capability.
Warning: KiotaBuilder Discriminator EventElement is not inherited from Capability.
Warning: KiotaBuilder Discriminator SubmodelElement is not inherited from Capability.
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Post of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPostRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class WithSubmodelIdentifierItemRequestBuilder
Trace: KiotaBuilder Creating property submodelElements of submodelElementsRequestBuilder
Trace: KiotaBuilder Creating property Content of ContentRequestBuilder
Trace: KiotaBuilder Creating property Metadata of MetadataRequestBuilder
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Put of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPutRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Delete of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToDeleteRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class submodelElementsRequestBuilder
Trace: KiotaBuilder Creating class ContentRequestBuilder
Trace: KiotaBuilder Creating class MetadataRequestBuilder
Trace: KiotaBuilder Creating indexer WithIdShortPath-indexer
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Post of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPostRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class WithIdShortPathItemRequestBuilder
Trace: KiotaBuilder Creating property attachment of attachmentRequestBuilder
Trace: KiotaBuilder Creating property invoke of invokeRequestBuilder
Trace: KiotaBuilder Creating property Content of ContentRequestBuilder
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Put of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPutRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Patch of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Post of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPostRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Delete of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToDeleteRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class attachmentRequestBuilder
Trace: KiotaBuilder Creating method ToPatchRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating class ContentRequestBuilder
Trace: KiotaBuilder Creating class invokeRequestBuilder
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Put of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPutRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Delete of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToDeleteRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Get of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToGetRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Post of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method Patch of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPostRequestInformation of Kiota.Builder.CodeDOM.CodeType
Trace: KiotaBuilder Creating method ToPatchRequestInformation of Kiota.Builder.CodeDOM.CodeType
Critical: KiotaBuilder error generating the client: One or more errors occurred. (the type does not contain any information)

NSwag is a more popular code generator, but that one has never worked with any version of BaSyx or the IDTA openapi specs. With Milestone 3 it does seem to create a client for the Environment, but when I use it i get exceptions like Newtonsoft.Json.JsonSerializationException: Error converting value "GlobalReference" to type 'Beenen.MS.BaSyx.NSwag.KeyType'. Path 'result[8].semanticId.keys[0].type', line 1, position 2247.
To Reproduce

Run BaSyx locally. I've provided my docker compose file below.
Install the .NET SDK (8.0)
Use this powershell (or bash) script to generate the client with Kiota. I run this script inside the folder of a "BaSyx" C# project as my working directory.

dotnet tool install --global Microsoft.OpenApi.Kiota
kiota generate -l CSharp -o ./Generated -n BaSyx -d http://localhost:8084/v3/api-docs -c DiscoveryClient --exclude-backward-compatible --log-level Information --co
kiota generate -l CSharp -o ./Generated -n BaSyx -d http://localhost:8083/api-docs -c SubmodelRegistryClient --exclude-backward-compatible --log-level Information
kiota generate -l CSharp -o ./Generated -n BaSyx -d http://localhost:8082/api-docs -c ShellRegistryClient --exclude-backward-compatible --log-level Information
kiota generate -l CSharp -o ./Generated -n BaSyx -d http://localhost:8081/v3/api-docs -c EnvironmentClient --exclude-backward-compatible --log-level Trace

Expected behavior
I can generate client code using the BaSyx OpenAPI specs without errors. I can use the client code to easily interact with the API of BaSyx services.
BaSyx (please complete the following information):

BaSyx Version: 2.0.0-milestone-03.1

BaSyx configuration

compose.yaml

services:

  aas-environment:
    container_name: aas-environment
    image: eclipsebasyx/aas-environment:2.0.0-milestone-03.1
    restart: unless-stopped
    volumes:
      - "./aas-environment.properties:/application/application.properties"
    networks:
      - backend
    ports:
      - "8081:8081"
    depends_on:
      mongo:
        condition: service_healthy

  aas-registry:
    container_name: aas-registry
    image: eclipsebasyx/aas-registry-log-mongodb:2.0.0-milestone-03.1
    restart: unless-stopped
    volumes:
      - "./aas-registry.yml:/workspace/config/application.yml"
    networks:
      - backend
    ports:
      - "8082:8080"
    depends_on:
      mongo:
        condition: service_healthy

  submodel-registry:
    container_name: submodel-registry
    image: eclipsebasyx/submodel-registry-log-mongodb:2.0.0-milestone-03.1
    restart: unless-stopped
    volumes:
      - "./submodel-registry.yml:/workspace/config/application.yml"
    networks:
      - backend
    ports:
      - "8083:8080"
    depends_on:
      mongo:
        condition: service_healthy

  aas-discovery:
    container_name: aas-discovery
    image: eclipsebasyx/aas-discovery:2.0.0-milestone-03.1
    restart: unless-stopped
    volumes:
      - "./aas-discovery.properties:/application/application.properties"
    networks:
      - backend
    ports:
      - "8084:8081"
    depends_on:
      mongo:
        condition: service_healthy

  mongo:
    container_name: mongo
    image: mongo:5.0
    restart: unless-stopped
    environment:
      MONGO_INITDB_ROOT_USERNAME: REDACTED
      MONGO_INITDB_ROOT_PASSWORD: REDACTED
      ME_CONFIG_MONGODB_URL: mongodb://REDACTED:REDACTED@aasv2-mongodb:27017/
    networks:
      - backend
    volumes:
      - mongo-data:/data/db
      - mongo-config:/data/configdb
    healthcheck:
      test: mongo
      interval: 10s
      retries: 5
      start_period: 1s
      timeout: 5s

  aas-gui:
    container_name: aas-gui
    image: eclipsebasyx/aas-gui:v2-240801
    restart: unless-stopped
    networks:
      - backend
    ports:
      - "3001:3000"
    environment:
      AAS_DISCOVERY_PATH: "http://localhost:8084"
      AAS_REGISTRY_PATH: "http://localhost:8082"
      SUBMODEL_REGISTRY_PATH: "http://localhost:8083"
      AAS_REPO_PATH: "http://localhost:8081/shells"
      SUBMODEL_REPO_PATH: "http://localhost:8081/submodels"
      CD_REPO_PATH: "http://localhost:8081/concept-descriptions"

networks:

  backend:

volumes:

  mongo-data:
  mongo-config:

aas-discovery.properties
server.port=8081
spring.application.name=AAS Discovery Service
basyx.aasdiscoveryservice.name=aas-discovery-service

org.eclipse.digitaltwin.basyx.aasdiscoveryservice.backend.AasDiscoveryBackendProvider

basyx.backend=MongoDB
spring.data.mongodb.host=mongo
spring.data.mongodb.port=27017
spring.data.mongodb.database=aas-discovery
spring.data.mongodb.authentication-database=admin
spring.data.mongodb.username=REDACTED
spring.data.mongodb.password=REDACTED

basyx.cors.allowed-origins=*
basyx.cors.allowed-methods=GET,POST,PATCH,DELETE,PUT,OPTIONS,HEAD

aas-environment.properties
server.port=8081
spring.application.name=AAS Environment

basyx.backend = MongoDB
spring.data.mongodb.host=mongo
spring.data.mongodb.port=27017
spring.data.mongodb.database=aas-environment
spring.data.mongodb.authentication-database=admin
spring.data.mongodb.username=REDACTED
spring.data.mongodb.password=REDACTED

basyx.feature.mqtt.enabled=true
basyx.aasrepository.feature.mqtt.enabled=true
basyx.aasservice.feature.mqtt.enabled=true
basyx.submodelrepository.feature.mqtt.enabled=true

mqtt.hostname=emqx
mqtt.clientId=aas-environment
mqtt.port=1883

basyx.externalurl=http://localhost:8081

basyx.aasrepository.feature.registryintegration=http://aas-registry:8080
basyx.submodelrepository.feature.registryintegration=http://submodel-registry:8080

basyx.cors.allowed-origins=*
basyx.cors.allowed-methods=GET,POST,PATCH,DELETE,PUT,OPTIONS,HEAD

# To define the maximum size of file to be uploaded in a request (default 1 MB)
spring.servlet.multipart.max-file-size=1000MB

# To define the total request size for a multipart/form-data (default 10 MB)
spring.servlet.multipart.max-request-size=1000MB

aas-registry.yml
---
basyx:
  cors:
    allowed-origins: "*"
    allowed-methods: "GET,POST,PATCH,DELETE,PUT,OPTIONS,HEAD"

spring:
  data:
    mongodb:
      uri: mongodb://REDACTED:REDACTED@mongo:27017

submodel-registry.yml
---
basyx:
  cors:
    allowed-origins: "*"
    allowed-methods: "GET,POST,PATCH,DELETE,PUT,OPTIONS,HEAD"

spring:
  data:
    mongodb:
      uri: mongodb://REDACTED:REDACTED@mongo:27017

System (please complete the following information):

OS: Debian 12 (WSL), Docker version 27.1.1, build 6312585
CPU architecture: x86
Browser: chrome

Hi @arteeh ,
Thanks for raising this issue, we will discuss it internally and get back to you soon.

It seems that NSwag does work for the Environment API, but only after I change a bunch of enums in the OpenAPI spec from SCREAMING_SNAKE_CASE (like CO_MANAGED_ENTITY) to PascalCase (like CoManagedEntity). Related issue: #296
But NSwag has the annoyance of not being able to 'combine' multiple APIs. So when I make an API for the shell registry and the submodel registry, I'll end up with two AssetAdministrationShellDescriptor classes for example.
Kiota makes a file for each class, so I just generate code for every API and let things overwrite eachother.

I opened an issue at Kiota about the unclear error message. They added some logging that might help me investigate the problem on Kiota's end.
https://github.com/microsoft/kiota/issues/5136

Hi @arteeh
The API in the environment or in BaSyx is compliant with the IDTA specification, this is not an issue from BaSyx's side.
As you already figured it out.
Please refer to the official specification from the IDTA.

I gave the IDTA API spec another try and posted my findings in this issue: https://github.com/admin-shell-io/aas-specs-api/issues/285
Could you please keep this issue open until there is some way (through BaSyx or through IDTA) to get a useful C# client SDK for BaSyx?
(P.S. we are aware of the aas-core-works SDK for C#, but I wrote here why that is not a sufficient replacement for us. Code generation seems like the best option for reaching BaSyx API from C#, when it works.)

Sure, we will keep this issue open :)

The BaSyx dotnet SDK got an update to AAS V3. It seems to include clients as well. Please check if it includes the features that you need.


Segment creation with flexible file paths

Currently, we enforce segments to have certain file extensions. If record reader path is there, we will allow any extensions.

Codecov Report

Merging #3943 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #3943      +/-   ##
============================================
- Coverage     67.27%   67.26%   -0.01%
  Complexity        4        4
============================================
  Files          1032     1032
  Lines         50946    50946
  Branches       7119     7119
============================================
- Hits          34272    34268       -4
- Misses        14329    14333       +4
  Partials       2345     2345

Impacted Files
Coverage Δ
Complexity Δ

...lix/EmptyBrokerOnlineOfflineStateModelFactory.java
86.66% <0%> (-13.34%)
0% <0%> (ø)

...impl/dictionary/FloatOffHeapMutableDictionary.java
85.45% <0%> (-7.28%)
0% <0%> (ø)

...e/impl/dictionary/LongOnHeapMutableDictionary.java
88.88% <0%> (-6.67%)
0% <0%> (ø)

...e/operator/dociditerators/BitmapDocIdIterator.java
60.71% <0%> (-3.58%)
0% <0%> (ø)

...r/validation/RealtimeSegmentValidationManager.java
55% <0%> (-3.34%)
0% <0%> (ø)

...ot/core/query/pruner/ColumnValueSegmentPruner.java
85.91% <0%> (-2.82%)
0% <0%> (ø)

...mpl/dictionary/DoubleOffHeapMutableDictionary.java
70.9% <0%> (-1.82%)
0% <0%> (ø)

...not/broker/requesthandler/RangeMergeOptimizer.java
89.7% <0%> (-1.48%)
0% <0%> (ø)

...va/org/apache/pinot/common/data/TimeFieldSpec.java
92.59% <0%> (-1.24%)
0% <0%> (ø)

.../pinot/core/common/datatable/DataTableBuilder.java
78.94% <0%> (-1.17%)
0% <0%> (ø)

... and 12 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 9786d50...21619e8. Read the comment docs.


bibtex retrieval (might be) actually not needed

We might actually not need to retrieve the bib at all since we have the information in the main page (see image above). We might just need to parse that information to fill the profile. @ipeirotis

Seems a lot of work to implement parsing logic for these entries. I will mark this issue as "wontfix / closed", and we can reopen in the future if it seems that this is required.


Application gets blocked on db connection acquisition if more than 10 concurrent clients connect

I'm not sure if it's about this application or this is a property of all http4s / doobie / hikari applications. It seems that something gets stuck when there are more clients connected than available connections in the connection pool.
How to reproduce:

do sbt dist (to remove the sbt environment as a factor)
unpack and run the app
run siege http://localhost:8080/users

Use top, htop or whatever to monitor system activity. You will notice nothing is happening. After 30 seconds exceptions start popping up:
[scala-execution-context-global-33] ERROR o.h.s.service-errors - Error servicing request: GET /users from <IP_ADDRESS>
java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms.
	at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:676)
	at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:190)
	at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:155)
	at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:128)
	at doobie.util.transactor$Transactor$fromDataSource$FromDataSourceUnapplied.$anonfun$apply$5(transactor.scala:260)
	at cats.effect.internals.IORunLoop$.cats$effect$internals$IORunLoop$$loop(IORunLoop.scala:87)
	at cats.effect.internals.IORunLoop$.startCancelable(IORunLoop.scala:41)
	at cats.effect.internals.IOBracket$BracketStart.run(IOBracket.scala:86)
	at cats.effect.internals.Trampoline.cats$effect$internals$Trampoline$$immediateLoop(Trampoline.scala:70)
	at cats.effect.internals.Trampoline.startLoop(Trampoline.scala:36)
	at cats.effect.internals.TrampolineEC$JVMTrampoline.super$startLoop(TrampolineEC.scala:93)
	at cats.effect.internals.TrampolineEC$JVMTrampoline.$anonfun$startLoop$1(TrampolineEC.scala:93)
	at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
	at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:85)
	at cats.effect.internals.TrampolineEC$JVMTrampoline.startLoop(TrampolineEC.scala:93)
	at cats.effect.internals.Trampoline.execute(Trampoline.scala:43)
	at cats.effect.internals.TrampolineEC.execute(TrampolineEC.scala:44)
	at cats.effect.internals.IOBracket$BracketStart.apply(IOBracket.scala:72)
	at cats.effect.internals.IOBracket$BracketStart.apply(IOBracket.scala:52)
	at cats.effect.internals.IORunLoop$.cats$effect$internals$IORunLoop$$loop(IORunLoop.scala:136)
	at cats.effect.internals.IORunLoop$RestartCallback.signal(IORunLoop.scala:351)
	at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:372)
	at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:312)
	at cats.effect.internals.IOShift$Tick.run(IOShift.scala:36)
	at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)

Stop the siege tool and observe the report:
** SIEGE 4.0.4
** Preparing 25 concurrent users for battle.
The server is now under siege...^C
Lifting the server siege...
Transactions:		           0 hits
Availability:		        0.00 %
Elapsed time:		       71.92 secs
Data transferred:	        0.00 MB
Response time:		        0.00 secs
Transaction rate:	        0.00 trans/sec
Throughput:		        0.00 MB/sec
Concurrency:		        8.22
Successful transactions:           0
Failed transactions:	          34
Longest transaction:	       61.85
Shortest transaction:	        0.00

Now if you restart the app and run siege again, but limit the number of concurrent "users" to 10:
$ siege -c10 http://localhost:8080/users
** SIEGE 4.0.4
** Preparing 10 concurrent users for battle.
The server is now under siege...^C
Lifting the server siege...
Transactions:		      134101 hits
Availability:		      100.00 %
Elapsed time:		       11.06 secs
Data transferred:	        0.26 MB
Response time:		        0.00 secs
Transaction rate:	    12124.86 trans/sec
Throughput:		        0.02 MB/sec
Concurrency:		        9.26
Successful transactions:      134101
Failed transactions:	           0
Longest transaction:	        0.03
Shortest transaction:	        0.00

Everything works OK. Why 10? This application does not configure the Hikari connection pool so defaults are used.
I am entirely unable to debug this but I thought I'd share my findings.

Hey thanks so much for reporting. I reviewed your PR, happy to discuss there or in gitter.

@irumiha thanks for finding this.
10 is the max number of connections in the connection pool (unless specified otherwise) - https://github.com/brettwooldridge/HikariCP
Since we are using the same thread pool throughout, eventually if you have more requesters than connections, those additional concurrent requests will block/wait for a connection to get freed up.  Too many users and then too many will block and eventually time out waiting for a connection.
We have double trouble as we use the same execution context for servicing requests AND making database calls.
Realistically, changing the max pool size feels like it should help out.  Definitely using a separate service execution context from your database calls which are blocking on IO will help as well (that you already found out).

Thanks @irumiha for your fix in #150


Improvements in sound

Hi Antony,
I wanted to ask you if there is the possibility of having sound improvements such as an equalizer and compressor.
Best regards.

@gonzo041 Thanks for your suggestion. Sorry no, this won't be in the scope of the project. There are several good quality applications that focus on EQ and compression. Equalizer APO is one such that may be useful. https://sourceforge.net/projects/equalizerapo/
Utilities like Equalizer APO allow you to modify most aspects of the PC sound so could also be used - for example - to compress the recording channel for audio out to the conference system.


[Pins] Setting for folders to open as new tab

Extension
https://www.raycast.com/HelloImSteven/pins
Description
I would like to be able to set an option for folders to open them as new tabs rather than separate windows. I guess they should be added to the most recent finder window, if several are open.
Who will benefit from this feature?
Anyone frequently opening sets of folders.
Anything else?
No response

It respects Finder's "Open folders in new tabs instead of new windows" setting. If you have that enabled, it will do exactly as you've described. I'm not sure a separate setting for Pins is needed, but let me know if you think otherwise.

On my system, Finder's "Open folders in new tabs instead of new windows" setting is not respected. It is turned on, but each folder is opened as a separate windows (not tabs of a single window) and not even when a finder window with tabs is already open…
Notwithstanding this potential bug, I think it would be useful to set a default and be able to tune the setting per folder.

The bug would be with Raycast's open() function, as Pins just calls that with the path to the folder. I'll submit a bug report on Slack.
I can look into adding a per-folder setting that uses AppleScript or something to ensure opening in the same-window.


Ranches DNS temporaily fails on occasion

Rancher Version:
1.1.2
Docker Version:
1.10.3
OS and where are the hosts located? (cloud, bare metal, etc):
AWS-Ubuntu 14.04.4
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single node rancher with external DB
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Every once in a while, on rancher, containers fail to resolve external DNS names. Not sure of what was happening, I created a python container that just resolves a url every couple seconds, and reports when the dns layer fails. https://gist.github.com/nhumrich/8bb1503eaef312e65ebd65b2fb075e9f
and eventually ran into:
 All nameservers failed to answer the query {my.url}. IN A: Server <IP_ADDRESS> UDP port 53 answered The DNS operation timed out.; Server <IP_ADDRESS> UDP port 53 answered The DNS operation timed out.; Server <IP_ADDRESS> UDP port 53 answered The DNS operation timed out.; Server <IP_ADDRESS> UDP port 53 answered SERVFAIL

Which basically means <IP_ADDRESS> timed out, or sent a SERVFAIL
so the dns is failing occasionally.
Queston 1: where is "<IP_ADDRESS>". Does that map to the networking agent on the same host as the query? Does that map to the rancher master? or could it go to ANY host in the environment?
Second, dns can fail. Any recommendations as to how to do failover, so when <IP_ADDRESS> is failing, another dns can be used?
Ideally, it would be great if you could figure out why the issue is happening, but some way to do failover is sufficient.

<IP_ADDRESS> is the Network Agent on the (same) host making the request.  It proxies requests for external domains to the upstream resolvers that are configured on the host (and tries all of them if there are multiple).

That's great but in this case this internal DNS itself is timing out. I even added a container that doesn't use rancher networking, and it had no issues during that time just using the host nameservers. Is there any way to add failover if the rancher networking agent itself isn't responding?

Having exact same issue, also in production. Will gladly provide any command output or whatever may be helpful in getting this figured out.
Couple of things that might matter:
on hosts machine i have google dns added to /etc/resolv.conf
nameserver <IP_ADDRESS>
and able to ping any internet site properly.
form the rancher/server container - not able to resolve anything
docker ps shows multiple instances of rancher/agent:v1.0.2 and rancher/agent-instance:v0.8.3 as running
problem began when I decided that it was a good idea to upgrade from 1.1.3 to 1.2.0.pre3. After upgrade rancher wasn't able to resolve anything and the rancher UI was making things not work.
I tried to downgrade to 1.1.3, upgrade to 1.1.4, still to no avail, DNS wouldn't work.
If i manually specify nameserver in container's /etc/resolv.conf file - it will work for a few moments, and then rancher will update my modification and comment google dns out and DNS would stop working again.
Any thoughts or ideas ? Thank you.

Linux will not retry a query if a server responds with an error.  A second "backup" server is only used if the connection to the main one times out or refuses connection, not because you received a failure response
The DNS server runs in the Network Agent container and might log something relevant.  Or you can edit /etc/init.d/rancher-dns and add -debug.
@virtuman There should be:

Exactly one running rancher/agenton each host
Exactly one rancher/agent-instance on each host for the Network Agent (publishing ports 500/4500)
Potentially several other rancher/agent-instances for load balancers (publishing no/other ports).

If you have multiple rancher agents or network agents then bad things are going to happen.  Usually this happens when people change the registration command and add things like --restart=always or --name=rancher-agent.  The registration command should have no name, run once, create rancher-agent-state and rancher-agent containers, and exit.

The DNS server runs in the Network Agent container and might log something relevant. Or you can edit /etc/init.d/rancher-dns and add -debug

I dont see any logs. Where exactly do I need to put the -debug statement inside of /etc/init.d/rancher-dns?

In the arguments; https://github.com/rancher/rancher-dns/blob/master/content/etc/init.d/rancher-dns#L16

closing due to inactivity.


Errors due to undefined progress cause all Obsidian hotkeys to become unresponsive until Obsidian restart

As reported in #173, it seems like something changed in Obsidian's loadProgress API since version 1.6.0. Any reference to progress causes errors that prevent exports from working.
Another side effect of these errors is that Obsidian hotkeys stop working, until you restart Obsidian (https://github.com/mokeyish/obsidian-enhancing-export/issues/173#issuecomment-2106555966).
Steps to reproduce
1a. Run an export with "Show export progress bar" enabled
1b. Run an export that fails for any reason, triggering progress.hide() in catch (err) in exporto0o.ts.
2. Try any Obsidian hotkey, like ctrl + p or ctrl + ,.
3. The hotkeys don't work.
Here's the error that occurs in scenario 1b:
plugin:obsidian-enhancing-export:28 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'hide')
    at Rn (plugin:obsidian-enhancing-export:28:2932)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async HTMLButtonElement.ge [as $$click] (plugin:obsidian-enhancing-export:28:9390)

All hotkeys stop working until restart of Obsidian, after this error occurs, or the error in #173.

duplicated with #173


Text Editor not coming at heroku

HI
Did any face this issue, Text Editor not coming at heroku?
Even i tried to run asset precompile at local and than push to heroku.
some one please suggest what to do in this case? see the screenshot

Yes I had the same issue.  I solved it by using "non-stupid-digest-assets".  See here:  https://github.com/alexspeller/non-stupid-digest-assets
I created an initializer here:
config/initializers/non_digest_assets.rb

And added this line to it:
NonStupidDigestAssets.whitelist += [/ckeditor\/.*/]

Thanks @eterry1388
This worked for me :+1:

Thanks eterry1388 , I just ran into this today after changing my site's theme from Zurb to Bootstrap.  That gem did the trick!


input is broken with heredoc

in repo https://github.com/BWITS/tf_aws_api_gateway_method I try to export the README with terraform-docs, but it is broken with heredoc
https://github.com/BWITS/tf_aws_api_gateway_method/blob/master/variables.tf#L48-L52
variable "integration_error_template" {
+   default = <<EOF
+ #set ($errorMessageObj = $util.parseJson($input.path('$.errorMessage')) {
+   "message" : "$errorMessageObj.message"
+ }
+ EOF
}

What I get, which should be in one line.
+| integration_error_template | # Velocity template used to deliver errors to response. Assumes all responses uses the same error template. | `#set ($errorMessageObj
+  "message" : "$errorMessageObj.message"
+}
+` | no |

terraform-docs is latest version
terraform-docs --version
v0.1.0

Seems the problem has been fixed by  #13, but not sure why I still have this issue.

ic. the PR (#13) fixed the heredoc issue in description only, we need fix default as well.

Raised #39 to fix this issue.


Added AJAX Request to load repo info

By this way, you would not need to manually update the data as stars, forks or issues.

@fergthh You're the man! Thanks for this!

@fergthh Wonder if you'd take a stab at making the number of downloads work like you did the Github stats. Here is the documentation for the Packagist API, maybe you'd be able to work with that? If so, making it just X.XK would be fantastic, just because there isn't much room on that page for adding extra numbers to that stat.. Let me know what you think!

Yes, I think an excellent idea! :) Let me check the documentation and i
will start to implement it ;)

Done @austintoddj ;)


Arlon Create Cluster Command

As a user of Arlon I would like the CLI to allow cluster creation based on three inputs:

ClusterSpec,
Profile, and
Git repository

The create cluster command will read the ClusterSpec from the Git repo that Arlon is configured to work with, read the Profile from where Arlon is configured to work with and then write the new clusters configuration to the Git Repository specified.
This will mean that each cluster has a distinct structure in Git, that is separate to the Git Repository where each ClusterSpec and Profile is stored.
The create command will also interact with ArgoCD APIs and create the related application objects for the Cluster and Profile.

For 0.3.x the command is called arlon cluster deploy


[branch-0.7] missed try catch.

What is this PR for?
Currently we can not build on branch-0.7
The cause is a missed try catch.
So, I fixed this part.
What type of PR is it?
Hot Fix
Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

merge


Add dimmed attribute

Also see https://github.com/BurntSushi/termcolor/pull/34

Released as 0.2.4


Daemon should provide tx fee estimates for all transactions

The Issue
Currently, there is no way to estimate what the transaction fees are when sending LBC, creating channels or publishing files.  This is a cause of friction from the user experience for two main reasons: 1) they try to send (or publish with) their entire LBC balance withtout taking into account fees, so the transaction does not go through (https://github.com/lbryio/lbry-app/issues/903 / https://github.com/lbryio/lbry-app/issues/874). 2) Users are currently unaware that there is some unrecoverable fee associated with transactions/claims/publishes.
Jack mentioned that lbryum already has a fee estimator, so it just needs to be exposed to all daemon commands which interact with sending LBC.
System Configuration

Anything Else

Screenshots

@lyoshenka I'm putting this on the user wish list because it causes UX friction in a few different scenariois, see below. It also may be related to: https://github.com/lbryio/lbry/issues/855

When creating a channel or publishing, some users may enter a value that's equal to their wallet balance and the result is https://github.com/lbryio/lbry-app/issues/874

When trying to send an amount that equal to your wallet balance, you may run into: https://github.com/lbryio/lbry-app/issues/873

When sending tips, you'll run into a similar issues because fees aren't taken into account.

steps:

[] make a lbryum command which takes an amount, creates a transaction, and figure out how big it is. then return estimateFeeForSize(tx_size)
[] for a publish, add in claim info into the above command
[] make lbrynet command that does these
[] write tests
[] pr review

Now that https://github.com/lbryio/lbryum/pull/234 was implemented, we need to take this into account when calculating fees.
I think it would make a lot of sense to work on this ASAP since the fees for claim txs has gone up considerably. Right now there are lots of edge cases where errors don't return properly if a user's balance doesn't cover the fee.
We also need to figure out how/when to run this function to update: https://github.com/lbryio/lbry/blob/master/lbrynet/daemon/Daemon.py#L97 in a way that is efficient as possible since it's called on each publish/update/channel creation.

@eukreign will the new wallet include this?

This is available in new wallet by creating TXs and showing them but not broadcasting them, the JSON response includes the fees.


Feature feedback: service-access

I proposed this idea back in #84, you graciously expanded & implemented it, and now, like a brat, I don't use the feature; I'd like to give some usage feedback.
concerns with cf-mgmt workflow:
I can't selective disable one service/service-plan or selectively re-enable it for specific orgs without configuring service access settings for every other org.
For example, in order to selectively-enable the "p.mysql" broker's "cdr-double-xl" plan for a limited number of orgs, I have to "affirm" access for every single org for all the other service plans except "cdr-double-xl", and then only the selected orgs which I want to give access would have "cdr-double-xl" listed.
This makes managing service access a bit unruly, and requires updating every org if a new service broker or service plan is added, changed, or removed.
This is also problematic because the blanket "disable service access" including orgs which aren't managed by cf-mgmt. For example, I have the system org whitelisted, so I don't have a config/system definition for it. So when I use service_access for other orgs, it disables access for all orgs first, including system, rendering all services in system unavailable.
current usage
Currently we use a pipeline called cf-service-access-mgmt using the cf-cli-resource. Here's a basic snippet from our prod foundation:
jobs:
- name: enforce-service-access-state
  serial: true
  plan:
  - get: ((trigger_interval))
    trigger: true

  - put: p-circuit-breaker-dashboard
    resource: cf-env
    params:
      commands:
      - {command: disable-service-access, service_broker: p-circuit-breaker-dashboard}
      - {command: enable-service-access, service_broker: p-circuit-breaker-dashboard, access_org: integration-automation}
      - {command: enable-service-access, service_broker: p-circuit-breaker-dashboard, access_org: system}

  - put: p-rabbitmq
    resource: cf-env
    params:
      commands:
      - {command: disable-service-access, service_broker: p-rabbitmq}
      - {command: enable-service-access, service_broker: p-rabbitmq, access_org: system}
      - {command: enable-service-access, service_broker: p-rabbitmq, access_org: p-spring-cloud-services}

  - put: p-redis
    resource: cf-env
    params: {command: disable-service-access, service_broker: p-redis}

  - put: "p.mysql-v2"
    resource: cf-env
    params:
      commands:
      - {command: disable-service-access, service_broker: "p.mysql", plan: "cdr-double-xl"}
      - {command: enable-service-access, service_broker: "p.mysql", plan: "cdr-double-xl", access_org: tenzing}
      - {command: enable-service-access, service_broker: "p.mysql", plan: "cdr-double-xl", access_org: gwx-green}
      - {command: enable-service-access, service_broker: "p.mysql", plan: "cdr-double-xl", access_org: cdwi}

This pipeline works in a two-step flow:

Disable service access to the service plan for everyone
Immediately selectively re-enable the service plan for the listed given orgs/spaces

This works well because I can selectively disable a single plan and re-enable the plan for given orgs, while simultaneously leaving other plans of the service instance alone. So for example, I can disable "cdr-double-xl" in "p.mysql", but that leaves the "db-xlarge", "db-large", etc. plans completely untouched from the global defaults.
ideas
We need an ability to disable specific service brokers or service plans for everyone, and selectively enable them for a few orgs. For everything else we don't explicitly configure, we prefer it to be untouched.
Therefore, it could be beneficial to have a centralized serviceAccess.yml which looks similar to the pipeline above, where disable: and enable: blocks can be defined. I made this up in a few minutes, so I really haven't thought through the implications yet.
# in `serviceAccess.yml`, or maybe in `orgs.yml`?
disable:
- service_broker: "yugabyte" # maybe this would disable everything for everyone?
- service_broker: "p.mysql"
   plan: "cdr-double-xl"
   orgs: # would be "all" if omitted
   - org_a
   - org_b

enable:
- service_broker: "yugabyte"
  orgs: # "plan" omitted, so enable all plans to these orgs
  - system
  - aegershman-org
- service_broker: "p.redis"
   plan: "big-ol-honkin-redis"
   orgs: # would be "all" if omitted
   - system # system isn't a managed org, but it could still be listed?
   - aegershman-org
- service_broker: "p.rabbitmq"
   plan: "big-rabbit" # enables access to everyone?

Don't mean to sound ungrateful or anything, but any thoughts?

@aegershman Not ungrateful :)  Valid feedback based on the user experience of how this is currently designed.  Let me think about how we can update using the feedback above.  Stay tuned....

@aegershman
Here's the format that I am planning to more forward with in cf-mgmt.yml config file.
service-access:
- service: p.mysql # would enable for the org listed as well as any protected org
  plan: db-medium
  orgs:
  - cfdev-org
- service: p.mysql # would disable for access for this plan for all orgs
  plan: db-large
  disable: true
- service: p.rabbitmq # would enable for all plans for all orgs (aka public)
- service: p.redis # would enable for all plans for only cfdev-org and all protected orgs
  orgs:
  - cfdev-org
- service: p.random # would disable for access for all plans for all orgs
  disable: true

Unless I'm missing something I believe with this format I can accomplish all of the scenarios above.
Let me know if you have any questions.  Will be working through how to migrate the current format of service-access away from in each org.yml file.

Right on, will get some coworker feedback + will think more on this later today & next few days 👍

I converted some of our existing service-access config over to the proposed syntax and came away with feedback. I have a bit more after this, will include in later comment.
also, goes w/o saying, but obvious I'm not trying to commandeer the use-case, fully respect the decision you take with it, etc., etc., but here's some takeaways I have:
broker ambiguity
as per cf enable-service-access -h, there may be a situation where the service name is ambiguous which requires the broker to be specified
cf enable-service-access SERVICE [-b BROKER] [-p PLAN] [-o ORG]

-b Enable access to a service from a particular service broker. Required when service name is ambiguous

presumably this could be solved by making the broker and optional field
- service: "p.mysql-v2"
  broker: dedicated-mysql-broker
  plan: "db-small-single-node"
  orgs:
  - myorg1
  - myorg2

orgs: [] ambiguity
What happens if I specify an empty array of orgs? Does it disable access to all orgs and then enables it for all the protected orgs? That's actually a pretty decent option, in my opinion. If specifying orgs: [x,y] will enable a service for the orgs x and y and all the protected orgs, then specifying an empty orgs array should only make the service/plan available to everything in protected.
- service: "p.mysql-v2"
  plan: "db-small-single-node"
  orgs: []

Which I assume is different from the following situation, which will disable (... I assume?) access to all orgs including the protected orgs
- service: "p.mysql-v2"
  plan: "db-small-single-node"
  disabled: true

disabled ambiguity
This situation could be a bit confusing. I assume that if disabled: true then params like orgs: would be ignored. I don't know if there's a way to either warn/fail on this config case or ensure that the cf-mgmt-config command will remove the entire orgs key when setting the service to disable... Or if nothing will happen at all and it's up to users to maintain their config properly. I don't know, but I can definitely see this happening:
- service: db-small-single-node
  disabled: true
  orgs:
  - groundworks
  - enterprise-services-poc

consider barfing if broker/service/plan not found
If a broker/service/plan isn't found registered against the cf foundation, should the job fail immediately? My view is "probably, yeah", because it helps avoid both mistakenly thinking something was properly configured and prevents config drift, wherein config for brokers/services/plans are left around and never cleaned up even if they don't exist against the cf foundation anymore
relevance of ordering
Does ordering matter? Let's say I have 7 different plans for some reason. I want all of them to be enabled EXCEPT for two of the plans. One of those plans, db-very-expensive, should be disabled to everyone (why is it still around? No idea. Work with me here.) The other of those plans, db-small-single-node, should only be available to two orgs. Now we're in a situation where either:

I specify every service & plan I want enabled by default, which is reasonable but verbose
I say "enable this service and all plans", followed by commands that say "... but disable plan db-very-expensive, and make plan db-small-single-node only available to [these-orgs]". That would look like this:

# enable service and all it's plans to everyone...
- service: "p.mysql-v2"

# ... EXCEPT db-very-expensive, which is deactivated...
- service: "p.mysql-v2"
  plan: "db-very-expensive"
  disabled: true

# ... AND EXCEPT db-small-single-node, which is only available to these two orgs:
- service: "p.mysql-v2"
  plan: "db-small-single-node"
  orgs:
  - myorg1
  - myorg2

If this is unordered/parallel, there's a race condition; if enabling the service and all it's plans triggers after the other two, it renders them useless.
Regardless of whether doing this is a good idea or not it should probably be documented whether this is considered to operate in order/parallel?
As a sidenote, a more explicit albeit verbose solution is to explicitly define all other plans of the service as "enabled":
# example of explicitly declaring all plans of a service as enabled. Any plans NOT declared in this config are considered "indeterminate"
- service: "p.mysql-v2"
  plan: db-small
- service: "p.mysql-v2"
  plan: db-medium
- service: "p.mysql-v2"
  plan: db-large
- service: "p.mysql-v2"
  plan: db-pretty-large-but-not-too-large
- service: "p.mysql-v2"
  plan: db-galera-small
- service: "p.mysql-v2"
  plan: db-galera-medium
- service: "p.mysql-v2"
  plan: db-galera-large
- service: "p.mysql-v2"
  plan: db-very-expensive
  disabled: true
- service: "p.mysql-v2"
  plan: db-small-single-node
  orgs:
  - myorg1
  - myorg2

I think it's worth reassessing the structure of the access config schema.
Having many individual entries will get cluttered.  Let's hone in on the the aws-service-broker (in other foundations we have the azure-broker, which has just as many plans/services. This list will only continue to grow... super cool)
In order to make all the aws-related plans available to myorg1, and assuming we aren't configuring enabling/disabling specific plans like aws-rds-aurora/basic vs. aws-rds-aurora/enterprise, etc. the minimum config would be this:
access
- service: aws-dynamodb
  orgs:
  - myorg1
- service: aws-rds-aurora
  orgs:
  - myorg1
- service: aws-rds-mariadb
  orgs:
  - myorg1
- service: aws-rds-mysql
  orgs:
  - myorg1
- service: aws-rds-oracle
  orgs:
  - myorg1
- service: aws-rds-postgres
  orgs:
  - myorg1
- service: azure-servicebus
  orgs:
  - myorg1
- service: aws-rds-sqlserver
  orgs:
  - myorg1
- service: aws-s3
  orgs:
  - myorg1
- service: aws-sqs
  orgs:
  - myorg1

And again, when we need to explicitly declare plans, that's more entries:
access
- service: aws-dynamodb
  orgs:
  - myorg1

# aws-rds-aurora
- service: aws-rds-aurora
  plan: basic
  orgs:
  - myorg1
- service: aws-rds-aurora
  plan: enterprise
  orgs:
  - myorg1
- service: aws-rds-aurora
  plan: premium
  disabled: true
- service: aws-rds-aurora
  plan: standard
  orgs:
  - myorg1

# aws-rds-mariadb
- service: aws-rds-mariadb
  plan: basic
  orgs:
  - myorg1
- service: aws-rds-mariadb
  plan: enterprise
  orgs:
  - myorg1
- service: aws-rds-mariadb
  plan: premium
  disabled: true
- service: aws-rds-mariadb
  plan: standard
  orgs:
  - myorg1

# aws-rds-mysql
- service: aws-rds-mysql
  plan: basic
  orgs:
  - myorg1
- service: aws-rds-mysql
  plan: enterprise
  orgs:
  - myorg1
- service: aws-rds-mysql
  plan: premium
  disabled: true
- service: aws-rds-mysql
  plan: standard
  orgs:
  - myorg1

# aws-rds-oracle
- service: aws-rds-oracle
  plan: basic
  orgs:
  - myorg1
- service: aws-rds-oracle
  plan: enterprise
  orgs:
  - myorg1
- service: aws-rds-oracle
  plan: premium
  disabled: true
- service: aws-rds-oracle
  plan: standard
  orgs:
  - myorg1

# aws-rds-postgres
- service: aws-rds-postgres
  plan: basic
  orgs:
  - myorg1
- service: aws-rds-postgres
  plan: enterprise
  orgs:
  - myorg1
- service: aws-rds-postgres
  plan: premium
  disabled: true
- service: aws-rds-postgres
  plan: standard
  orgs:
  - myorg1

# aws-rds-sqlserver
- service: aws-rds-sqlserver
  plan: basic
  orgs:
  - myorg1
- service: aws-rds-sqlserver
  plan: enterprise
  orgs:
  - myorg1
- service: aws-rds-sqlserver
  plan: premium
  disabled: true
- service: aws-rds-sqlserver
  plan: standard
  orgs:
  - myorg1

- service: aws-s3
  orgs:
  - myorg1
- service: aws-sqs
  orgs:
  - myorg1

This is demoing the config for only this one broker. This is pretty intense, in my opinion.
In a comment below I'm about going to workshop out some ideas, so bare with me. Unclear if this is the best model, how feasible it is to implement, not trying to impose, etc. Just sharing.
(more thoughts on the way, am writing them up again--)

last one:
Is there benefit to consolidating the model to have plans: be a list on the service struct?
using the aws-broker example:
access:
- service: aws-dynamodb
  orgs:
  - myorg1

# aws-rds-aurora
- service: aws-rds-aurora
  plans:
  - plan: basic
    orgs:
    - myorg1
  - plan: enterprise
    orgs:
    - myorg1
  - plan: premium
    disabled: true
  - plan: standard
    orgs:
    - myorg1

# aws-rds-mariadb
- service: aws-rds-mariadb
  plans:
  - plan: basic
    orgs:
    - myorg1
  - plan: enterprise
    orgs:
    - myorg1
  - plan: premium
    disabled: true
  - plan: standard
    orgs:
    - myorg1

# aws-rds-mysql
- service: aws-rds-mysql
  plans:
  - plan: basic
    orgs:
    - myorg1
  - plan: enterprise
    orgs:
    - myorg1
  - plan: premium
    disabled: true
  - plan: standard
    orgs:
    - myorg1

# aws-rds-oracle
- service: aws-rds-oracle
  plans:
  - plan: basic
    orgs:
    - myorg1
  - plan: enterprise
    orgs:
    - myorg1
  - plan: premium
    disabled: true
  - plan: standard
    orgs:
    - myorg1

# aws-rds-postgres
- service: aws-rds-postgres
  plans:
  - plan: basic
    orgs:
    - myorg1
  - plan: enterprise
    orgs:
    - myorg1
  - plan: premium
    disabled: true
  - plan: standard
    orgs:
    - myorg1

# aws-rds-sqlserver
- service: aws-rds-sqlserver
  plans:
  - plan: basic
    orgs:
    - myorg1
  - plan: enterprise
    orgs:
    - myorg1
  - plan: premium
    disabled: true
  - plan: standard
    orgs:
    - myorg1

- service: aws-s3
  orgs:
  - myorg1
- service: aws-sqs
  orgs:
  - myorg1

So not perfect, but we do have fewer lines of code && fewer top-level keys in the access: list. It makes it easier to organize and reduces visual clutter. Purely speculative but I imagine this could benefit the cf-mgmt-config global service-access logic/UX too? This way all the plans for a service are under a single service object, so you don't need to look up every service: key name of every entry in the access list? ... Again, idk, just spitballing.
more alternative struct ideas
As was said in a comment above, if you want to do something like "enable ALL plans of a service to everyone, EXCEPT for a few select limiting rules-- for example, "make all mysql plans available to everyone, EXCEPT only make db-really-expensive available to one org" or something-- it's contingent on these service-access rules being ordered and sequential.
Assuming the above structure, what if there were a key for something like enable-all-first?
That way, instead of this:
- service: "p.mysql-v2"
  plans:
  - plan: db-small
  - plan: db-medium
  - plan: db-large
  - plan: db-pretty-large-but-not-too-large
  - plan: db-galera-small
  - plan: db-galera-medium
  - plan: db-galera-large
  - plan: db-very-expensive
    disabled: true
  - plan: db-small-single-node
    orgs:
    - myorg1
    - myorg2

You could do this:
# I'm going to come back to this example down below
- service: "p.mysql-v2"
  enable-all-first: true
  plans:
  - plan: db-very-expensive
    disabled: true
  - plan: db-small-single-node
    orgs:
    - myorg1
    - myorg2

consolidating the model under broker?
As we know from cf service-access we can see the UX organizes by BROKER, then by SERVICE, then by SERVICE PLAN. What if we follow that model in the config, too?
access:
- broker: aws-services-broker # "broker" as top level key; prevents the requirement of repeating `broker` as part of each `service` model
  services:
  - service: aws-dynamodb
    orgs:
    - myorg1
  - service: aws-rds-aurora
    plans:
    - plan: basic
      orgs:
      - myorg1
    - plan: enterprise
      orgs:
      - myorg1
    - plan: premium
      disabled: true
    - plan: standard
      orgs:
      - myorg1
  - service: aws-rds-mariadb
    plans:
    - plan: basic
      orgs:
      - myorg1
    - plan: enterprise
      orgs:
      - myorg1
    - plan: premium
      disabled: true
    - plan: standard
      orgs:
      - myorg1

using broker: as top-level key might naturally replace idea of "enable-all-first"?
Assuming these lists are ordered and sequential, then model has the benefit of naturally featuring the idea of enable-all-first, because you can specify the service such that it'd have all plans available to everyone. For example:
Instead of this, which requires enable-all-first to have all the service's plans be made available to everyone and THEN have specific plans be limited/controlled...
- service: "p.mysql-v2"
  enable-all-first: true
  plans:
  - plan: db-very-expensive
    disabled: true
  - plan: db-small-single-node
    orgs:
    - myorg1
    - myorg2

... you, hypothetically, could do this:
- broker: p.mysql
  services:
  - service: "p.mysql" # enables ALL plans of service "p.mysql" to all orgs
  - service: "p.mysql" # followed immediately by config which enforces limits on each plan
    plans:
    - plan: db-very-expensive
      disabled: true
    - plan: db-small-single-node
      orgs:
      - myorg1
      - myorg2

this could also be used to disable all services/plans first, then selectively enable a plan to certain orgs?
- broker: p.mysql
  services:
  - service: "p.mysql"
    disabled: true
  - service: "p.mysql"
    plans:
    - plan: db-small-single-node
      orgs:
      - myorg1
      - myorg2

If specifying multiples of the same service: xyz is problematic, then EITHER something like enable-all-first: true (again, not sure if that's a good idea or not) could be specified, OR the expectation just be that admins explicitly declare all the plans for a given service in order to enable/disable them. It adds more lines of code, but if it means a cleaner programming model / conceptual model, then boo hoo, the added lines of code are definitely clearly worth it.
considerations/downsides

Does all of this add too much complexity?

What would the CLI UX look like?! Would it be attrocious?

If ordering of list entries matters, can a CLI UX account for that?
Must keep in mind that normal, regular, non-cf-mgmt-expert users submitting PRs are going to be using this.

How are brokers, services, plans, etc. added and removed via the CLI?

Should service-access the job blow right the hell up (exit 1) if a broker/service/plan/org defined in config doesn't exist on the foundation? (If this is put to a vote, my opinion is "yes" in order to prevent mistakes, config drift, etc.)

If broker is used as top-level key, downside is the broker name is less commonly known? Easy solution though, which is just look it up from cf-cli using cf service-access, it'll spit it right out.

Anyway that's pretty much all the feedback I've got for the moment. Please don't feel compelled to rush (let alone implement?) this unless you're totally jazzed about the conceptual model. I feel like service-access is one of the more complicated configuration setups.
Disclaimer because I feel guilty about asking without directly contributing: if you feel these ideas are total trash, then hey, that's cool-- I mean, a little harsh, but, okay-- and I understand if they aren't taken into account during design/implementation. I'm not able to write go, so it's not like I can contribute much except use-cases and hypothetical ideas.
... Alright so with all that said, please let me know if there's anything I can do to help. Thanks for reading all this, hope it was beneficial!

I definitely think this should emulate the how service-access is viewed.  So agree need to introduce the broker as a level of organization and see how that can clean up the amount of clutter.  Thanks for the feedback I'll experiment with a few options and circle back.

@aegershman Here's what I have come up with.  Wanting to see if this covers the scenarios and if this UX seems reasonable.   All these configs are in cf-mgmt.yml

Default setup where all plans are public

enable-service-access: true
service-access: {}

Making some plans limited all other plans will be all access.  Any plan for the broker/service that is not listed will remain public access.  Any plan listed in limited_access_plans will be limited to the org names and anything in protected orgs list.

service-access:
- broker: dedicated-mysql-broker
  services:
  - service: p.mysql
    limited_access_plans:
    - plan: db-large
      orgs:
      - cfdev-org

which is equivalent to the following
service-access:
- broker: dedicated-mysql-broker
  services:
  - service: p.mysql
    all_access_plans:
    - db-small
    - db-medium
    limited_access_plans:
    - plan: db-large
      orgs:
      - cfdev-org

Having a mix of limited, no access and all access

service-access:
- broker: dedicated-mysql-broker
  services:
  - service: p.mysql
    all_access_plans: # available for all orgs
    - db-small
    no_access_plans: # available to no orgs
    - db-medium
    limited_access_plans:
    - plan: db-large # available to cfdev-org and protected orgs (ie system, etc)
      orgs:
      - cfdev-org

And example of multiple brokers, services to see configuration will look.
service-access:
- broker: rabbitmq-odb
  services:
  - service: p.rabbitmq
    all_access_plans:
    - single-node-3.7
- broker: p-rabbitmq
  services:
  - service: p-rabbitmq
    all_access_plans:
    - standard
- broker: dedicated-mysql-broker
  services:
  - service: p.mysql
    all_access_plans:
    - db-small
    limited_access_plans:
    - plan: db-medium
    - plan: db-large
      orgs:
      - cfdev-org

Thanks in advance for the feedback.  Been helpful to walk through the scenarios.  Trying to balance ease of use vs magic where if not listed assume that is is public so you can use the format above to be very explicit or to have default behavior match what happens when you install a broker.  I could also add a flag to default-service-access: all | none` to allow customizing this

Give me just a little bit to review this + mock out what it would be like for our current usage, will get back to you ASAP. Thanks again 👍

@calebwashburn i think this has a lot of potential.  For an initial step this would solve a lot of the issues that @aegershman and myself have with managing service access.  For an initial first go I think this would work and after using it in practice we would know more what could be refined.

@calebwashburn also I don't want to put you in a position similar to the first implementation of service-access: {} where now that it's implemented it's harder to change/remove without bumping semver. If you felt it's appropriate to mark this as experimental we could consume it in 1.0.31+ and give you another round of feedback once we start consuming it at work?
Not trying to tell you how to run your product, just don't want to be whiny or put your features in limbo

Added with https://github.com/pivotalservices/cf-mgmt/releases/tag/v1.0.31


Using anon functions in a nested @. function

Another one from me — I'm adding these because I think this library is superb and I'm exploring how far it can go — I realize the past few issues have been corner cases.
Building on https://github.com/jkrumbiegel/Chain.jl/issues/42, this works:
s = "dbaf fag bdfgea ecbgfa dgbfe fa edacg agcfdbe cefdbg fdgea | fgbaed cdegbf dacfbge gdcfbe
abc acefbd gacedbf gbcde dgabf ca fgcedb cega dgbca cgeadb | ca bcged abgfd bca"

function inner(x)
    (x -> split(x, "|"))(x)
end

input = @chain s begin
    strip

    split("\n")
    @. inner
end

But if we replace inner with the function, it fails:
input = @chain s begin
    strip

    split("\n")
    @. (x -> split(x, "|")) # (or with (_) at the end)
end

# You can only use the @. macro and automatic first argument insertion if what follows is of the form `[Module.SubModule.]func`

My understanding from the docs is that that should be syntactic sugar for this, which also works:
input = @chain s begin
    strip

    split("\n")
    (x -> split(x, "|")).(_)
end

You could just do split.(x, "|")? I'm not sure if adding the overhead for recognizing anonymous functions makes so much sense given all the other options to write this.

For sure in this specific case there's no need, and I agree it's not important. It can be useful on the margin when debugging, or copying code from elsewhere. I was mostly surprised it wasn't consistent, rather than really needing it.
It's a corner case, and very reasonable to deprioritize. Thanks.