Feature request: iOS support

Hello @hadynz
I’m trying to work entirely from my iPad (actually my computer died not long ago).
I haven’t been able to sync my highlights since then and was wondering if it would be complicated to add iOS compatibility to your plugin.
I assume it could be useful to a lot of people.
Many thanks

Same here. +1.
What are the issues/reasons it can't work?

The plugin fetches Kindle Highlights from Amazon cloud by logging in with your credentials and screen scraping. Obsidian desktop is built using Electron which allows you to easily to do the screen scraping. The mobile app does not use Electron.
So the current core method that the app uses will not work on mobile. A completely different approach would have to be thought through. So it is certainly non-trivial.

@jelomu I wonder if it's viable to have iOS Shortcuts scrape it and dump it in the vault folder. Difficult since it required authentication.
Maybe Drafts is an intermediary option?
I see this method of fetching highlights using Javascript. But that uses Puppeteer just as this uses Cheerio.

The Puppeteer scraper uses Good Reads and not Amazon Cloud. The former is easy to login into via a script. The latter could require you to enter 2FA and is harder to automate.
Nevertheless, there is potentially a way to do it. Just hasn't been a priority - although I can see several people are upvoting this request now. So might be something that I will need to consider.

Would love this to happen. I’m kicking the tyres again. Such a good plugin, but the inability to pull from my night-time reading over coffee in the morning is hurting :-)

Absolutely waiting for the same thing! My only device is my ipad - no access to a desktop/laptop to do things like this just to still do everything on ipad.


Updates to chapters.vtt do not show up on the player

If I make any changes to my locally hosted chapters.vtt file, they don't get reflected in the player - even after clearing the browser cache and local storage. The player still displays the old chapters.
Note: here is my code...nothing special here, I am using the default HLS installation as mentioned on the install page:
<!DOCTYPE html>
<html>
<head>

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/vidstack/styles/defaults.min.css" />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/vidstack/styles/community-skin/video.min.css" />
<script type="module" src="https://cdn.jsdelivr.net/npm/vidstack/dist/cdn/prod.js"></script>

</head>
<body>
    <media-player
        title="Name this video anything you want!"
        src="/456/original__video_file.m3u8"
        poster=""
        thumbnails="/456/thumbnails.vtt"
        aspect-ratio="16/9"
        crossorigin
    >
        <media-outlet>
            <media-poster
                alt="Girl walks into sprite gnomes around her friend on a campfire in danger!"
            ></media-poster>
            <track
                src="https://media-files.vidstack.io/sprite-fight/subs/english.vtt"
                label="English"
                srclang="en-US"
                kind="subtitles"
                default
            />
            <track
                src="/456/chapters.vtt"
                srclang="en-US"
                kind="chapters"
                default
            />
        </media-outlet>
        <media-community-skin></media-community-skin>
    </media-player>

</body>
</html>

This issue is outdated now and should be resolved since our new 1.0@next release. If the issue persits after upgrading, feel free to let me know here and we can reopen. If the issue has changed then please open a new one.
Do note, we don't perform any caching at the moment on any captions/chapters VTT files. There's no way for the player to remember the previous chapters. It must be some kind of caching happening at the browser or network level.


feat: highlight

What does this PR change?

...
How to test the changes?

Launch the explorer
...

Our Code Review Standards
https://github.com/decentraland/unity-renderer/blob/master/docs/code-review-standards.md

@LucasLioyQA to test, you can check that the interactables (NPCs also) are highlighted as expected.

These elements get stuck showning the outline once you mouse over them

Issue shown on yesterday's comment seems to be ok now:
https://github.com/decentraland/unity-explorer/assets/146749313/df7c0c4a-0219-4fba-89e8-50131c276126
https://github.com/decentraland/unity-explorer/assets/146749313/f5d77b84-4e1f-4d04-862b-7550e72dda82
Issue mentioned on thread (highlighting sometimes doesn't properly work) hasn't been seen so far:
https://github.com/decentraland/unity-explorer/assets/146749313/5a7e616a-f2f1-4117-8c5c-efaf0be223b2
https://github.com/decentraland/unity-explorer/assets/146749313/322c966d-43a7-47a9-ad07-4e4f860387e5


Cif 751 add to cart button

CIF 751 add to cart button integration
Description
Add to cart button should add the items to cart as described in CIF-751
https://jira.corp.adobe.com/browse/CIF-751
How Has This Been Tested?
Go to any product page:
Select variant ,  color if applicable and click add to cart button. Cart opens and Item gets added in cart.
Screenshots (if appropriate):
Types of changes
Minor change to integrate product page button and cart.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes and the overall coverage did not decrease.
[ ] All unit tests pass on CircleCi.
[ ] I ran all tests locally and they pass.

Codecov Report

Merging #47 into master will decrease coverage by 10.9%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master      #47       +/-   ##
=============================================
- Coverage     56.88%   45.97%   -10.91%
  Complexity      135      135
=============================================
  Files            25       21        -4
  Lines           842      659      -183
  Branches         49       49
=============================================
- Hits            479      303      -176
+ Misses          340      333        -7
  Partials         23       23

Flag
Coverage Δ
Complexity Δ

#karma
?
?

#unittests
45.97% <ø> (-0.16%)
135 <ø> (ø)

Impacted Files
Coverage Δ
Complexity Δ

...erce/core/components/internal/models/v1/Utils.java
60% <0%> (-2.07%)
8% <0%> (ø)

...onents/internal/models/v1/product/VariantImpl.java
75.86% <0%> (-0.81%)
13% <0%> (ø)

...onents/models/productcarousel/ProductCarousel.java
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

...ternal/models/v1/product/VariantAttributeImpl.java
90% <0%> (ø)
6% <0%> (ø)
:arrow_down:

...onents/internal/models/v1/product/ProductImpl.java
37.83% <0%> (ø)
20% <0%> (ø)
:arrow_down:

...mponents/internal/models/v1/product/AssetImpl.java
63.15% <0%> (ø)
8% <0%> (ø)
:arrow_down:

...s/internal/models/v1/product/VariantValueImpl.java
85.71% <0%> (ø)
4% <0%> (ø)
:arrow_down:

...nal/models/v1/searchresults/SearchResultsImpl.java
77.58% <0%> (ø)
19% <0%> (ø)
:arrow_down:

...nternal/models/v1/productlist/ProductListImpl.java
31.18% <0%> (ø)
14% <0%> (ø)
:arrow_down:

...models/v1/productcarousel/ProductCarouselImpl.java
27.08% <0%> (ø)
4% <0%> (ø)
:arrow_down:

... and 6 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 401dd4a...47ae83d. Read the comment docs.


Can not use USE_SEGGER_RTT

Describe the bug
When trying to use USE_SEGGER_RTT, I get the following fault

warning: USE_SEGGER_RTT (defined at modules\segger\Kconfig:12) was assigned the value 'y' but got
the value 'n'. Check these unsatisfied dependencies: HAS_SEGGER_RTT (=n), 0 (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_USE_SEGGER_RTT and/or look up
USE_SEGGER_RTT in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

To Reproduce
Steps to reproduce the behavior:

Clone fresh zephyr install using west
Build this sample: west build -p always -b nrf52833dk_nrf52833 samples/bluetooth/hci_uart

I did no changes to the code to get the warning shown above, so this is either bug with zepyhr or something in the sample configuration is wrong.
Expected behavior
RTT should be enabled.
This bug prevents from using RTT in the current latest release (west update) of zepyhr.
More context
I have checked what HAS_SEGGER_RTT is selected by (https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_HAS_SEGGER_RTT) and it is selected by CONFIG_SOC_SERIES_NRF52X (https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_SOC_SERIES_NRF52X) so not sure why this is not working.
Board nrf52833dk_nrf52833 defines CONFIG_SOC_SERIES_NRF52X so this seems ok, but still the error happens.
It used to work properly in older versions of zepyhr in the same sample, but since I updated it, this is happening.

Works fine for me, you probably forgot to do west update or you have a manifest which blocks getting the segger repo

This has happened after I ran west update. I was able to use RTT just fine before running this command after picking up the project after a while

you have a manifest which blocks getting the segger repo

Where can I check that?

you have a manifest which blocks getting the segger repo

Where can I check that?

Are you using a custom manifest or west init && west update directly?

Ok, I see what you mean, I use https://github.com/zephyrproject-rtos/example-application for the base of the workspace.
Strange that it worked before.
What do I need to add in west.yml for this to work?

Ok got it, sorry for the confusion.
For anyone having a similar problem, one needs to either remove name-allowlist or add segger to it if using https://github.com/zephyrproject-rtos/example-application


🛡 High Memory Consumption leading to Network Outage

[!NOTE]
Severity: Critical
target: v7.1.0 - Commit: 3c854270b006db30aa3894da2cdba10cc31b8c5f
Ref: OKP4 Blockchain Audit Report v1.0 - 02-05-2024 - BlockApex

Description
While approaching the prolog code being executed on the okp4 blockchain, we used blackbox approach in which we tried various prolog predicates which were natively allowed in the blockchain. We found that if a large list is generated and then tried to be mapped, it would cause a high memory usage which may lead to termination of that specific blockchain instance. This issue was
also verfied on itchiban/prolog's Scripting engine. If a large list i.e N =<PHONE_NUMBER>0 was passed it would cause high memory usage that the node instance is forced to terminate. It is interesting to note that on some value of N = 10000, the blockchain will gracefully handle the issue and return gas error.
Furthermore, it was tested that this issue is applicable for all predicates that may have a high memory consumption.
This finding is not isolated to our custom testing environments but was also corroborated using the Ichiban Prolog's scripting engine, highlighting a fundamental issue within the underlying computational logic that poses a serious risk to the blockchain's stability and operational integrity.
Impact
The ramifications of this vulnerability are twofold:

Single Node Crash: An attacker could exploit this vulnerability to specifically target a single node by sending a query that triggers the high memory consumption issue. This would result in the node crashing due to memory overload, leading to potential disruptions in service and degradation of network performance.
Multiple Node Failure: More alarmingly, this vulnerability could be exploited through a valid transaction propagated across the network. If such a transaction contains a smart contract or operation that invokes the problematic Prolog predicates, it could lead to simultaneous high memory consumption on multiple nodes. This scenario could cause widespread network outages or even facilitate a network takeover by malicious validators who could remain operational while others fail.

Recommandation
TBC

Below is my analysis and steps to reproduce the critical issue at hand. Let's open discussion about this issue and potential solutions to resolve it.
📏 length/2 allocation issue
Initially, I thought the issue was due to the recursive call of execution of all clauses through maplist/2. However, the recursion is not the problem since the logic module asks for prolog execution through a given context that handles the out of gas limit. The context is given to the Promise that handles each predicate and stops immediately when the gas limit is reached.
When calling length(List, 4), prolog will allocate a new Variable four times and unify it into the List :
https://github.com/axone-protocol/prolog/blob/d6ea3496c94deb1dbb755c4e2c78914507c67d0b/engine/builtin.go#L2926-L2935  :
func lengthRundown(vm *VM, list Variable, n Integer, k Cont, env *Env) *Promise {
	elems, err := makeSlice(int(n))
	if err != nil {
		return Error(resourceError(resourceMemory, env))
	}
	for i := range elems {
		elems[i] = NewVariable()
	}
	return Unify(vm, list, List(elems...), k, env)
}

The only limitation checked here is the memory limit depending on the node host caught by  makeSlice(). Otherwise, for very large numbers, it takes time to allocate NewVariable() through the loop range and is not handled by the context limitation. This means, when we call this predicate through a context with a deadline :
func TestInterpreter_performance(t *testing.T) {
	var out bytes.Buffer
	p := New(nil, &out)

	tests := []struct {
		name     string
		query    string
		output   string
		outputFn func(t *testing.T, output string)
		err      error
		waits    bool
	}{
		{name: "1", query: `length(List, 10000000), maplist(=(1), List).`, err: context.DeadlineExceeded, waits: true},
		{name: "2", query: `length(List,<PHONE_NUMBER>0), maplist(=(1), List).`, err: context.DeadlineExceeded, waits: true},
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			ctx, cancel := context.WithTimeout(context.Background(), 10000*time.Millisecond)
			defer cancel()

			assert.Equal(t, tt.err, p.QuerySolutionContext(ctx, tt.query).Err())
			assert.Equal(t, tt.waits, errors.Is(ctx.Err(), context.DeadlineExceeded))
		})
	}
}

The first test case works since the deadline is handled by maplist, but the second one fails due to the test timeout and not handled by the context cancellation.
Workaround
I made a small workaround for testing purposes by adding the context to the VM and using it to check if the context is not done before continuing :
func lengthRundown(vm *VM, list Variable, n Integer, k Cont, env *Env) *Promise {
	elems, err := makeSlice(int(n))
	if err != nil {
		return Error(resourceError(resourceMemory, env))
	}
	for i := range elems {
		select {
		case <-vm.Ctx.Done():
			fmt.Println("TIME OUT")
			return Error(fmt.Errorf("time out"))
		default:
			elems[i] = NewVariable()
		}
	}
	return Unify(vm, list, List(elems...), k, env)
}

💾 Memory limit
Here is the snippet of code that is used for making a new slice by controlling available memory :
https://github.com/axone-protocol/prolog/blob/d6ea3496c94deb1dbb755c4e2c78914507c67d0b/engine/malloc.go#L14-L43
The calculation of the memory limit for making a new slice is not safe and will depend essentially on the host where the node runs. It's not safe because between the time when the available memory is checked (free := memFree()) and when the slice is allocated (make([]Term, n)), another part of the program could potentially allocate memory, causing the actual memory usage to exceed the limit. (In a blockchain node execution condition, this occurs multiple times on my side during my test). By the way, we cannot catch memory overflows : https://github.com/ichiban/prolog/issues/226.
🔗 References

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/length#29
https://www.swi-prolog.org/pldoc/man?predicate=length/2
https://github.com/mthom/scryer-prolog/issues/1325
https://github.com/ichiban/prolog/issues/191
https://github.com/ichiban/prolog/issues/226

📝 Next steps
Let's discuss possible fixes we can implement 😅. @ccamel @amimart

Thanks @bdeneux for your detailed analysis of the nature of the security problem revealed by the audit.
Regarding the length/2 allocation issue, we can't use the deadline pattern to solve it because it introduces unpredictability into the execution of requests. Depending on the complexity of the query and the current load on the system, the same query may sometimes succeed and sometimes fail, compromising the ability of the validation nodes to reach consensus.
In preliminary consideration, I believe the best approach would be to implement controls on the allocators (memory, variables, etc.) that:

Ensure that the amount allocated of resources (mem, variables, etc) cannot exceed a maximum, which assures validators that allocated resources remain constrained at all times. This serves as the absolute limit.
Account for this allocation by a proportional consumption of gas. This acts as the utilitarian limit.

That said, it's not easy, quite tricky (as you mentioned, https://github.com/ichiban/prolog/issues/226 is a good read)
and you have to apply it to all the code, mainly in the ichiban/prolog library, but also to our native predicates, if necessary.
But I'd need a bit more time to get a better grasp of the issue and see if other approaches might not be more effective and safer.

@ccamel @bdeneux This is really tricky, I would propose a first far from ideal fix: prohibit unification of the length with a variable using the length/2 predicate, same approach could be use for the functor/3 predicate. This way we can still get the length of an array, but initializing one..
What do you think?


Error: signal: Segmentation fault (core dumped) on Ubuntu Server 20.04 Linux ARM 64-bit

Scenario

I'm running pscale 0.89 on Ubuntu Linux 64-bit on Raspberry Pi 3 B+ (ARM64)
I'm running pscale inside a Docker container, using the Ubuntu base image (docker run -it ubuntu:latest)
I promoted the main branch to production
I used "pscale shell" to connect to the production branch
I received an error (see below)

Actual Result
root@f8ef97c5103b:/# pscale branch promote trevor main
Branch main in trevor was successfully promoted.
root@f8ef97c5103b:/# pscale shell trevor main
Error: signal: segmentation fault (core dumped)

However, pscale shell works perfectly fine connecting to a dev branch.
root@f8ef97c5103b:/# pscale shell trevor dev1
trevor/dev1>

Expected Result

Successful connection to main (production) branch
Error indicating that connecting to production branches is unsupported

Also ran into the same problem using Docker Desktop on Windows 11, when connecting to a production branch. So, we at least know it's not just an ARM CPU issue.

Exactly the same issue, running in a Docker container (vscode devcontainer) using Debian Bookworm, macOS 13.1.
pscale shell connects to a dev branch just fine, but segmentation faults connecting to the production branch. Outside Docker just running on macOS, pscale shell connects to either branch okay.


Atlantis for iOS stopped working after upgrading to Mac OS Big Sur

Hi Team,
After I upgraded my Mac to Big Sur, my Atlantis is not able to track the network traffic in Proxyman. Can anyone help to resolve this issue?
Thanks in advnce.

Hey @axnmax, I'm using Big Sur and I would like to clarify that Atlantis works fine here 👍
To investigate, please help me:

Make sure you turn OFF the Firewall in System Preference -> Security & Privacy -> Firewall
Please update to the latest Atlantis with pod update

and use the following code to connect to your macOS
Atlantis.start(hostName: "_your_host_name")

You can find the hostname in the Atlantis window from Proxyman for macOS 👍

Hi @NghiaTranUIT,
I followed the steps as described by you.
Still it does not work for me. It used to work perfectly for me before I upgraded to Big Sur.

I just tested again and it works with Atlantis 1.10.0 and Big Sur. I'm not sure why Atlantis doesn't work in your end 🤔
When you open Atlantis, do you see any log message like:
---------------------------------------------------------------------------------
---------- 🧊 Atlantis is running (version 1.10.0)
---------- Github: https://github.com/ProxymanApp/atlantis
---------------------------------------------------------------------------------
[Atlantis] Looking for Proxyman app in the network...
Reachability Status Changed: reachable(Alamofire.NetworkReachabilityManager.NetworkReachabilityStatus.ConnectionType.ethernetOrWiFi)
[Atlantis] Found Proxyman with HostName = Nghias-Mac-mini.local.
[Atlantis] ✅ Connect to Nghias-Mac-mini.local.

If Bonjour Service finds any Macbook which has Proxyman, it will list it
[Atlantis] Found Proxyman with HostName = Nghias-Mac-mini.local.

If you could not see anything, look like your network is blocking the Bonjour Service @axnmax

Yes I am able to see the logs as you mentioned. But the Proxyman does not show any traffic.

---------- 🧊 Atlantis is running (version 1.10.0)
---------- Github: https://github.com/ProxymanApp/atlantis
[Atlantis] Looking for Proxyman app in the network...
[Atlantis] Found Proxyman with HostName = axnmax.local.
[Atlantis] ✅ Connect to axnmax.local.

Look like it's a bug @axnmax 🤔
Atlantis is connecting to Proxyman, but it doesn't send any message.
If you don't mind, please help me to debug:

Start Proxyman and Atlantis => Make sure you can see the log: [Atlantis] ✅ Connect to axnmax.local.
Set a breakpoint on two place:

https://github.com/ProxymanApp/atlantis/blob/9d125e08268437e4231bcbae99cccb337d5ee5df/Sources/Transporter.swift#L109
https://github.com/ProxymanApp/atlantis/blob/9d125e08268437e4231bcbae99cccb337d5ee5df/Sources/Transporter.swift#L114

Try to make a request and see which breakpoint is stopped.
And set a breakpoint after Atlantis sends a message at
https://github.com/ProxymanApp/atlantis/blob/9d125e08268437e4231bcbae99cccb337d5ee5df/Sources/Transporter.swift#L137

Since I could not access to your codebase, so I could debug. Please help me if you don't mind. I appreciate it 🙇

The control only reaches line 109. It did not go to lone 114 and 137 anytime.

Thanks for getting back to me. Just wondering:

Which iOS version are you using?
Are you using Atlantis on a real iOS Device or iOS Simulator? 🤔

iOS 13.2.3
Real iOS Device

Also there is an update on the breakpoints, last time it did not connect to the local host.  The control only reaches line 114. It did not go to line 109 and 137 anytime.

Thanks. I will investigate the bug. Meanwhile, please try on iOS Simulator, it should work 😄


Remove privileged flag

It should suffice to remove --privileged and instead use just --cap-add=NET_ADMIN --cap-add=NET_RAW
Not sure if this is docker version specific.

The change has been commited, thanks for the feedback!


Don't use my license Badge

What about generating you own badge.?
There are tons of forks out there that use the license of my color-list.


[Question] Frequency and Overhead of Cluster Allocation in Simulation

Hello,
I have a question regarding the cluster simulation discussed in the paper.
How frequently does cluster allocation occur in the simulation? Additionally, how much computational overhead is involved in this process? There are concerns about the scalability of the system as the number of nodes increases. Could you provide more details?
Thank you!

Thank you for reaching out with your inquiry.
As stated in the paper, the cluster allocation is performed when a new inference service is added, the cloud configuration is altered, or the expected peak request rate of an inference service is changed. All these events are sporadic.
The complexity of solving Eq. 1 can be approximated to O($mC^m\sum_j (X^{max}_j)^2$), where $C$ is a constant. However, because of ILP solvers' optimization techniques, it is difficult to accurately identify parameters' impact to the computation time. A single-threaded solver took only 35 seconds for cluster allocation when there are 12,000 GPUs of 10 different types serving 100 ML models. If a cloud expands to the point where solving Eq. 1 becomes infeasible, we can partition the cloud into sub-groups.


gardenmap: integrate Leaflet

Integrate the Leaflet into the Gardenmap component. For the time being, only an example image is to be displayed.

[x] integrate Leaflet
[ ] discuss tile provider (Mapbox, OpenStreetMap, ...)
[x] use an example image to display

Implemented first workflow for placing an image on the map with 3 markers. Leaflet image rotation was used to perfectly fit the image to the points on the map.


feat(slug): callout and revert updates

Related Ticket(s)
Follow up to : https://github.com/carbon-design-system/carbon/pull/15522 & https://github.com/carbon-design-system/carbon/pull/15528
Description
This pulls in the new callout slug updates and updates to new carbon version
Changelog
New

slug callout styles
when slug revert is active then remove parent component background styles

Changed

updated carbon version
updated slug stories

Removed

{{removed thing}}

In the revert test, the number input is still showing a blue line under the buttons. This was a bug that slipped through TJs original PR as well.

Ahh yeah i saw his PR. We would have to wait for that PR to get added to the next release to pull in those updates

closing in favor for: https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/11453


Tool requires the github user/pass ?

Hi, When I try to run git-all-secrets, it requires the github user/pass, but when i watch the video demo, it doesn't.
Even I provided the correct github user/pass, it still can't run :
$ docker run --rm -it abhartiya/tools_gitallsecrets:v6 -org=MyOrg -token=d2d2cf23d24d9e267d88d08b34caf48bne895776 -output=results.txt
Since org was provided, the tool will proceed to scan all the org repos, then all the user repos and user gists in a recursive manner
Cloning the repositories of the organization: MyOrg
[...skip repo info...]
Username for 'https://github.com': Username for 'https://github.com'<EMAIL_ADDRESS>Password for 'https://vietwow<EMAIL_ADDRESS>Password for<EMAIL_ADDRESS>panic: exit status 128

goroutine 28 [running]:
main.check(0x7fa4c0, 0xc420286780)
	/data/main.go:41 +0x100
main.gitclone(0xc4202feac0, 0x32, 0xc42030a9a0, 0x19, 0xc420280510)
	/data/main.go:54 +0x108
created by main.cloneorgrepos
	/data/main.go:93 +0x405

Anyone can help ? Thanks
Best Regards,
VietNC

@vietwow This tools only works for public github orgs and repos. Are you trying to run this for public orgs and repos?

Also, how did you generate your Github token?

Hi Anshuman,
Thank for your quick reply, ops, I ran it with private repo. So any plan for private repo scanning in the near future ?
Best Regards,
VietNC

if its your own private repo, you can generate a Github token from that account and use that token. Since your token will have access to your private repo, it should work. If you are trying to scan somebody else's private repo, then that is something you shouldn't really do, technically speaking.


Include txid info

Include the txid field in the Transactions TAB,  Also on the pop-up that displays after making a Transaction, would be a good idea to include the txid there also.

Accepted as an enhancement - will be done.

This feature is now implemented: After sending ZEN successfully the user may copy the transaction ID to the clipboard or view the transaction on the blockchain explorer.


Remove CODEOWNERS

See RFC: https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095
Vote thread: https://github.com/apache/tvm/issues/10471

cc @driazati @tqchen would it better to disable this mechanism instead of removing/moving the file?

Another option is to break down the various areas so a small change won't ping everyone? Currently it's very broad, and doing a bit of a folder structure clean up may help as the codebase has evolved a bit?

cc @driazati @tqchen would it better to disable this mechanism instead of removing/moving the file?

That would be nice but AFAIK GitHub doesn't have any setting for it so we're stuck with something like this if we want to keep this information around

Another option is to break down the various areas so a small change won't ping everyone? Currently it's very broad, and doing a bit of a folder structure clean up may help as the codebase has evolved a bit?

@Mousius sorry for the delay, but see the pre-RFC in https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095, it has a section on this

#10471 is closed in favor, this is ready to merge! @areusch

See followups in #10575


add concepts doc

@morey-tech and @nikita-akuity I would value your feedback on this doc.
Note that I don't intend for this page to explore every conceivable option in the Kargo resource types, nor every nuance of the controller. So if you see anything teased that isn't fully explained, just know that there's a reference section also coming soon and those details will all be there.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@f1024dc). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #328   +/-   ##
=======================================
  Coverage        ?   52.05%
=======================================
  Files           ?       38
  Lines           ?     3644
  Branches        ?        0
=======================================
  Hits            ?     1897
  Misses          ?     1674
  Partials        ?       73

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

Not waiting for full CI run for docs only change.


how to fix this problem

my environments:
CentOS 3.10.0-327.28.2.e17
server oracle 11g
client InstantClient 12
go 1.8

I can't figure out without codes.

@mattn Close this?


feat(query): added "Global Security Definitions Using Basic Authentication" to openAPI 2.0

Signed-off-by: Rafaela Soares<EMAIL_ADDRESS>Proposed Changes

Added "Global Security Definitions Using Basic Authentication" to openAPI 2.0

I submit this contribution under the Apache-2.0 license.

already implemented


Update README.md

Coverage remained the same at 89.639% when pulling 01c54351cfc8d3d30220199530aca74fe3b85600 on Lizhooh:master into 052232e32456da4751d789b61e89aba4a07a7e25 on mozillazg:master.

Coverage remained the same at 89.639% when pulling 01c54351cfc8d3d30220199530aca74fe3b85600 on Lizhooh:master into 052232e32456da4751d789b61e89aba4a07a7e25 on mozillazg:master.

@Lizhooh Thanks!


If I want to design a binder for a trimer surface.

If this trimer has three identical chains DEF, and I wish to bind to certain hot spot amino acids on one of the chains (for example, residues 3-6 on chain D), do I need to rename the chains to ABC and renumber the amino acids for each chain starting from 1 before inputting the corresponding hot spot amino acids? When inputting the hot spot amino acids, do I need to input all the corresponding hot spots at the same positions for all three chains?
Additionally, I have tried outputting results, and BindCraft will default to outputting the trimer as a single chain A. Will this affect my design?
Thanks a lot.

You don't need to rename or renumber anything. You can enter hotspots for different chains by adding the chain name before it. For multiple chains you need to enter for each chain. For example
chains = "D,E,F"
hotspots = "D21,D22,D23,E21,E22,E23,F21,F22,F23"
No, it is meant to output the target as a merged A chain, that is normal


Import/export CLI tool mentioned -q flag

Description:
In the help option of the import/export CLI tool of the list apis command the -q --query flag is mentioned in the examples. However, this flag is not used in APIM 2.5.0. Therefore, it will be good if we can update the help information in the CLI import/export tool.
Suggested Labels:
2.5.0, improvement
Suggested Assignees:
Uvindra
Affected Product Version:
API-M 2.5.0 import/export CLI tool
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:

Closing the issue as this is older than 3 years. Please reopen if the issue is valid still.


[CARBONDATA-2181] Thread Leak during compaction processing on restructured table

Thread Leak during compaction processing on restructured table. The executor service which is being initialised has to be closed once processing finish or else error encountered.

[x] Any interfaces changed? No

[x] Any backward compatibility impacted? NA

[x] Document update required? NA

[x] Testing done Yes
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[x] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA. NA

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/3738/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2498/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/3536/

@sounakr I don't think it is required to do so many file changes to change exception throwing to fix the issue. I think change in CompactionResultSortProcessor.java  would be enough to fix this issue.

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/3034/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/4278/


unix,win: merge timers implementation

Merge src/unix/timer.c and src/win/timer.c into src/timer.c.  This
changes the Windows implementation from a binary tree to a binary
heap for generally better performance.
https://ci.nodejs.org/view/libuv/job/libuv-test-commit/922/ (infrastructure issue on macos buildbot)
~~https://ci.nodejs.org/view/libuv/job/libuv-test-commit/923/~~
~~https://ci.nodejs.org/view/libuv/job/libuv-test-commit/924/~~
https://ci.nodejs.org/view/libuv/job/libuv-test-commit/930/

Since this has already been done on master (https://github.com/libuv/libuv/commit/912d42b7285fc29869472106d1c736f34ac91521), do you anticipate any issues merging v1.x into master?

Oh, I'd forgotten about that.  There will be minor conflicts but nothing that's intractable.

CI-in-node: https://ci.nodejs.org/view/libuv/job/libuv-in-node/34/

The CI failures are expected. Once https://github.com/nodejs/node/pull/21466 lands in Node, the results should be better.

Landed in 07955ed3...e4087ded.


Is it possible to create a static library instead of shared library?

The current way of building with Cython will result in a shared library in the end, i.e. .so, is there a reason for us to build into .so?
I wonder if it could be built into a .o or static library file. The benefit of a static library is that we can combine everything into a single executable, instead for shared library we will have the binary loading the separate shared library file.

Yes, that possibility exists. You can link multiple extension modules together and use the "inittab" mechanism to load them into CPython.
https://docs.python.org/3/extending/embedding.html#extending-embedded-python
https://docs.python.org/3.5/c-api/import.html#c.PyImport_AppendInittab

Would it be possible to get a little more detail on this solution? I am relatively new to cython myself, but from these links it is unclear how I can convert my cython-generated shared library into a static library, or whether I can build the static library directly from cython. Thank you!

Does anyone have idea about it? I am facing the same problem now.


Cleanup contact2 (that was created via account2)

The sample did not cleanup all of the data it added.

@millarde-equinor Thanks for catching that.


Variable pagination

Pivotal ticket
On first load the page defaults to 50 records per-page for processed/deleted application indexes.
This adds a selector for 50/100/500/All to allow users to select their preference, for a single use of the page

👍  looks good!


Support 405, 406, 415

What is the issue about:
Methods support in Framework.
What happened:
nirvana doesn't support following methods right now:

405 Method Not Allowed
406 Not Acceptable
415 Unsupported Media Type

What you expected to happen:
All commonly used method should be supported
Anything else we need to know:
@caicloud/review-framework who wanna take this?

Personally I like 418

It's supported now.

@kdada are u working on this?  I'm thinking of assigning to someone else to get them familiar with the framework.
@caicloud/review-framework

@ddysher  ok.


Low overhead performance testing of Pilot

Right now its pretty hard to test pilot at scale, because we have gotten to the point where pilot can handle 1000+ connections on a single CPU, so in order to test pilot at even moderate scale you need a massive cluster.
We can fake load with direct XDS connections, service entries, etc -- but these are not exercising the same code paths, so they are not fully representative.
What I envision is a possibility to get pilot running, connected to a standalone api-server+etcd (no kubelet, etc). We have various tests for different scenarios - for example, creating a virtual service every 5s or whatever. There are various chunks of "scenarios" that compose together.
The important thing here is we can do something like create a Pod (just the resource, its not literally running anything) + Endpoint + Service, which will exercise the k8s code path very cheaply. We can then connect directly the Pilot using the IP we assigned that pod, and from Pilot point of view this is identical to a real k8s setup, except its WAY cheaper to run, and its much more flexible in what we can setup. We can easily test complex scenarios like pods flip-flopping between ready and not ready, rapid scaling, etc etc
I plan to work on this but don't have much time to invest right now, will likely be the thing I do when I have free time

I think we can have a single system with multiple types of "tests":

Simple Istio CR creation/deletion/modification. Example simulations are changing virtual service (simulate things knative or flagger does), creating gateway + SDS secrets and rotating frequently, modifying various configs (especially SE)
Fake API server simulating pods/endpoints/etc. Pilot connects using the multicluster code.
Fake XDS client

All of these are useful independantly. For example, we might want to just generate a bunch of XDS clients, and we also may want to just simulate a bunch of config changes. All together, however, they can accurate simulate pretty much all scenarios.

This is implemented in https://github.com/howardjohn/pilot-load


v4.35.1 启动半个小时之后开始无法连接到远端服务器

你正在使用哪个版本的 V2Ray？
v4.35.1

你的使用场景是什么？
使用 Chrome 通过 Socks/VMess 代理使用 GitHub

你看到的异常现象是什么？
每启动半个小时之后客户端开始无法连接到远端，重启客户端后恢复，半个小时后依然无法连接远端，如此往复
尝试重启过远端服务以及服务器，现象一致

你期待看到的正常表现是怎样的？
正常连接代理服务器
请附上你的配置

服务端配置：
// 在这里附上服务器端配置文件
{
  "log": {
    "loglevel": "warn",
    "access": "/var/log/v2ray/access.log",
    "error": "/var/log/v2ray/error.log"
  },
  "inbounds": [
    {
      "port": "1000",
      "listen": "<IP_ADDRESS>",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "xxxxxxxx",
            "alterId": 64
          }
        ]
      },
      "streamSettings": {
        "network": "h2",
        "security": "tls",
        "httpSettings": {
          "path": "/xxxxxxxx",
          "host": [
            "xxxxxxxx"
          ]
        },
        "tlsSettings": {
          "serverName": "xxxxxxxx",
          "certificates": [
            {
              "certificateFile": "/etc/letsencrypt/live/xxxx/fullchain.pem",
              "keyFile": "/etc/letsencrypt/live/xxxx/privkey.pem"
            }
          ]
        }
      }
    },
    {
      "port": 1024,
      "listen": "<IP_ADDRESS>",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "xxxxxxxx",
            "alterId": 64
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/xxxxxxxx"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "blocked"
      }
    ]
  }
}

客户端配置：
// 在这里附上客户端配置
{
  "inbounds": [
    {
      "protocol": "socks",
      "port": 1080,
      "listen": "<IP_ADDRESS>",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    },
    {
      "protocol": "http",
      "port": 1081,
      "listen": "<IP_ADDRESS>",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "xxxxxxxx",
            "port": 443,
            "users": [
              {
                "id": "xxxxxxxx",
                "alterId": 64
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "security": "tls",
        "network": "h2",
        "httpSettings": {
          "path": "/xxxxxxxx",
          "host": [
            "xxxxxxxx"
          ]
        }
      },
      "mux": {
        "enabled": true
      },
      "tag": "h2"
    },
    {
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "xxxxxxxx",
            "port": 443,
            "users": [
              {
                "id": "xxxxxxxx",
                "alterId": 64
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/xxxxxxxx"
        }
      },
      "mux": {
        "enabled": true
      },
      "tag": "cf"
    },
    {
      "protocol": "freedom",
      "settings": {},
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    }
  ],
  "dns": {
    "servers": [
      {
        "address": "<IP_ADDRESS>",
        "port": 53,
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "<IP_ADDRESS>",
        "port": 53,
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "<IP_ADDRESS>",
      "<IP_ADDRESS>",
      "<IP_ADDRESS>",
      "<IP_ADDRESS>",
      "<IP_ADDRESS>"
    ]
  },
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "outboundTag": "blocked",
        "domain": [
          "geosite:category-ads"
        ]
      },
      {
        "type": "field",
        "outboundTag": "direct",
        "domain": [
          "geosite:cn"
        ]
      },
      {
        "type": "field",
        "outboundTag": "direct",
        "ip": [
          "geoip:cn",
          "geoip:private"
        ]
      },
      {
        "type": "field",
        "outboundTag": "h2",
        "network": "udp,tcp"
      }
    ]
  }
}

请附上出错时软件输出的错误日志

服务器端错误日志：
// 在这里附上服务器端日志
无

客户端错误日志：
// 在这里附上客户端日志
Mar 11 10:56:30 rog systemd[1]: Started V2Ray Service.
Mar 11 10:56:30 rog v2ray[2014813]: V2Ray 4.35.1 (V2Fly, a community-driven edition of V2Ray.) Custom (go1.16 linux/amd64)
Mar 11 10:56:30 rog v2ray[2014813]: A unified platform for anti-censorship.
Mar 11 10:56:30 rog v2ray[2014813]: 2021/03/11 10:56:30 [Info] github.com/v2fly/v2ray-core/v4/main/jsonem: Reading config: /usr/local/etc/v2ray/config.json
Mar 11 10:56:30 rog v2ray[2014813]: 2021/03/11 10:56:30 [Warning] github.com/v2fly/v2ray-core/v4: V2Ray 4.35.1 started
Mar 11 10:57:59 rog systemd[1]: /etc/systemd/system/v2ray.service:7: Special user nobody configured, this is not safe!
Mar 11 10:58:00 rog systemd[1]: /etc/systemd/system/v2ray.service:7: Special user nobody configured, this is not safe!
Mar 11 10:58:01 rog systemd[1]: /etc/systemd/system/v2ray.service:7: Special user nobody configured, this is not safe!
Mar 11 10:58:02 rog systemd[1]: /etc/systemd/system/v2ray.service:7: Special user nobody configured, this is not safe!
Mar 11 11:35:07 rog v2ray[2014813]: 2021/03/11 11:35:07 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:11 rog v2ray[2014813]: 2021/03/11 11:35:11 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:15 rog v2ray[2014813]: 2021/03/11 11:35:15 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:19 rog v2ray[2014813]: 2021/03/11 11:35:19 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:23 rog v2ray[2014813]: 2021/03/11 11:35:23 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:27 rog v2ray[2014813]: 2021/03/11 11:35:27 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:31 rog v2ray[2014813]: 2021/03/11 11:35:31 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:35 rog v2ray[2014813]: 2021/03/11 11:35:35 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:39 rog v2ray[2014813]: 2021/03/11 11:35:39 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:41 rog v2ray[2014813]: 2021/03/11 11:35:41 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:45 rog v2ray[2014813]: 2021/03/11 11:35:45 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:49 rog v2ray[2014813]: 2021/03/11 11:35:49 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 11:35:53 rog v2ray[2014813]: 2021/03/11 11:35:53 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 12:28:11 rog v2ray[2014813]: 2021/03/11 12:28:11 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 12:28:15 rog v2ray[2014813]: 2021/03/11 12:28:15 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
Mar 11 12:28:19 rog v2ray[2014813]: 2021/03/11 12:28:19 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an
 available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "h
ttps://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed

请附上访问日志

// 在这里附上服务器端日志

其它相关的配置文件（如 Nginx）和相关日志
caddyfile
xxxxxxxx {
    log {
        output file /var/log/caddy/access.log
    }
    tls {
        protocols tls1.2 tls1.3
        ciphers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        curves x25519
    }
    reverse_proxy /xxxxxxxx <IP_ADDRESS>:1000 {
        header_up Host {host}
        header_up X-Real-IP {remote}
        header_up X-Forwarded-For {remote}
        header_up X-Forwarded-Port {server_port}
        header_up X-Forwarded-Proto "https"
        transport http {
            tls
            tls_insecure_skip_verify
        }
    }
    file_server {
        root /usr/share/caddy
    }
}

xxxxxxxx {
    log {
        output file /var/log/caddy/access.log
    }
    tls {
        protocols tls1.2 tls1.3
        ciphers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        curves x25519
    }
    reverse_proxy /xxxxxxxx <IP_ADDRESS>:1024
    file_server {
        root /usr/share/caddy
    }
}

如果 V2Ray 无法启动，请附上 --test 命令的输出
如果 V2Ray 服务运行异常，请附上 journal 日志

need server logs

截取了开头部分日志，剩下的日志都是一样的
2021/03/10 06:00:49 [Warning] github.com/v2fly/v2ray-core/v4: V2Ray 4.35.1 started
2021/03/10 06:00:49 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:00:50 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:01:11 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:01:50 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:02:32 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:02:53 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:14 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:14 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:15 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:15 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:15 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:20 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.

截取了开头部分日志，剩下的日志都是一样的
2021/03/10 06:00:49 [Warning] github.com/v2fly/v2ray-core/v4: V2Ray 4.35.1 started
2021/03/10 06:00:49 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:00:50 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:01:11 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:01:50 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:02:32 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:02:53 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:14 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:14 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:15 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:15 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:15 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.
2021/03/10 06:03:20 [Warning] github.com/v2fly/v2ray-core/v4/proxy/vmess/encoding: Critical Warning: potentially invalid user: a non VMessAEAD connection is received. From 2022 Jan 1st, this kind of connection will be rejected by default. You should update or replace your client software now.

服务器还有其他人在用，不确定其他人的客户端版本
上午将客户端降级到 4.34，问题没有出现了

这不是错误，这是提示。你的 VMess 没有启用 AEAD，所以提醒你升级为 VMessAEAD。

会不会日志太多了呢

会不会日志太多了呢

我服务器上 13min 产生了 200k error.log 和 68k access.log

{
  "inbounds": [
    {
      "protocol": "socks",
      "port": 1080,
      "listen": "<IP_ADDRESS>",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    },
    {
      "protocol": "http",
      "port": 1081,
      "listen": "<IP_ADDRESS>",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "xxxxxxxx",
            "port": 443,
            "users": [
              {
                "id": "xxxxxxxx"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "security": "tls",
        "network": "h2",
        "httpSettings": {
          "path": "/fbb768fc-1e88-4651-936a-8c2b0a499352",
          "host": [
            "us.lijinglin.dev"
          ]
        }
      },
      "mux": {
        "enabled": true
      },
      "tag": "h2"
    },
    {
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "us.lijinglin.net",
            "port": 443,
            "users": [
              {
                "id": "xxxxxxxx"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/3f252a84-7742-493a-b040-1ae9e5e24eb0"
        }
      },
      "mux": {
        "enabled": true
      },
      "tag": "cf"
    },
    {
      "protocol": "freedom",
      "settings": {},
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "settings": {},
      "tag": "blocked"
    }
  ],
  "dns": {
    "servers": [
      {
        "address": "<IP_ADDRESS>",
        "port": 53,
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "<IP_ADDRESS>",
        "port": 53,
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "<IP_ADDRESS>",
      "<IP_ADDRESS>",
      "<IP_ADDRESS>",
      "<IP_ADDRESS>",
      "<IP_ADDRESS>"
    ]
  },
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "outboundTag": "blocked",
        "domain": [
          "geosite:category-ads"
        ]
      },
      {
        "type": "field",
        "outboundTag": "direct",
        "domain": [
          "geosite:cn"
        ]
      },
      {
        "type": "field",
        "outboundTag": "direct",
        "ip": [
          "geoip:cn",
          "geoip:private"
        ]
      },
      {
        "type": "field",
        "outboundTag": "h2",
        "network": "udp,tcp"
      }
    ]
  }
}

客户端升级到 4.35.1，更新到上面的配置，还是会出现连不上的情况。我理解 AlterID 不配置，默认为 0 也是开启了 VMessAEAD？还是说我的配置有问题？

每半个小时重启一次进程，你应该关注error log和内核日志

内核日志没有异常，error log 只有客户端报错
Mar 11 17:44:48 rog v2ray[3037647]: 2021/03/11 17:44:48 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "https://us.lijinglin.dev:443/fbb768fc-1e88-4651-936a-8c2b0a499352": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed

本地测试了下过 proxy 连不上之后的连接

去掉 proxy 之后可以连接

你得想办法在服务器上观察进程，不管是调整配置还是什么 得抓到panic or stderr

升级了所有客户端，服务端无 potentially invalid user 警告，问题仍然存在
服务端降级到 4.34.0，问题仍然存在
客户端降级到 4.34.0，问题解决
服务端和客户端保持在 4.35.1，outbounds 切换为 cf(ws+tls)，问题解决

通过以上步骤，基本定位问题在 4.35.1 客户端的 h2 模式
附客户端无法访问服务端时的 error.log，其中 us.lijinglin.dev:443 为远端服务器
2021/03/13 18:23:54 [Info] github.com/v2fly/v2ray-core/v4/app/dns: DNS: created UDP client initialized for <IP_ADDRESS>:53
2021/03/13 18:23:54 [Info] github.com/v2fly/v2ray-core/v4/app/dns: DNS: created UDP client initialized for <IP_ADDRESS>:53
2021/03/13 18:23:54 [Info] github.com/v2fly/v2ray-core/v4/app/dns: DNS: created UDP client initialized for <IP_ADDRESS>:53
2021/03/13 18:23:54 [Info] github.com/v2fly/v2ray-core/v4/app/dns: DNS: created UDP client initialized for <IP_ADDRESS>:53
2021/03/13 18:23:54 [Info] github.com/v2fly/v2ray-core/v4/app/dns: DNS: created localhost client
2021/03/13 18:23:54 [Info] github.com/v2fly/v2ray-core/v4/transport/internet/tcp: listening TCP on <IP_ADDRESS>:1080
2021/03/13 18:23:54 [Info] github.com/v2fly/v2ray-core/v4/transport/internet/tcp: listening TCP on <IP_ADDRESS>:1081
2021/03/13 18:23:54 [Warning] github.com/v2fly/v2ray-core/v4: V2Ray 4.35.1 started
2021/03/13 18:32:48 [Info] [3674208782] github.com/v2fly/v2ray-core/v4/proxy/http: request to Method [CONNECT] Host [us.lijinglin.dev:443] with URL [//us.lijinglin.dev:443]
2021/03/13 18:32:48 [Info] [3674208782] github.com/v2fly/v2ray-core/v4/app/dispatcher: sniffed domain: us.lijinglin.dev
2021/03/13 18:32:48 [Info] github.com/v2fly/v2ray-core/v4/transport/internet/udp: establishing new connection for udp:<IP_ADDRESS>:53
2021/03/13 18:32:48 [Info] github.com/v2fly/v2ray-core/v4/app/dispatcher: taking detour [h2] for [udp:<IP_ADDRESS>:53]
2021/03/13 18:32:48 [Info] github.com/v2fly/v2ray-core/v4/common/mux: dispatching request to udp:<IP_ADDRESS>:53
2021/03/13 18:32:48 [Info] github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:us.lijinglin.dev:443
2021/03/13 18:32:49 [Info] github.com/v2fly/v2ray-core/v4/app/dns: UDP:<IP_ADDRESS>:53 got answer: us.lijinglin.dev. TypeA -> [<IP_ADDRESS>] 1.002876638s
2021/03/13 18:32:49 [Info] github.com/v2fly/v2ray-core/v4/app/dns: UDP:<IP_ADDRESS>:53 got answer: us.lijinglin.dev. TypeAAAA -> [] 1.110108172s
2021/03/13 18:32:49 [Info] [3674208782] github.com/v2fly/v2ray-core/v4/app/dispatcher: taking detour [h2] for [tcp:us.lijinglin.dev:443]
2021/03/13 18:32:49 [Info] [3674208782] github.com/v2fly/v2ray-core/v4/common/mux: dispatching request to tcp:us.lijinglin.dev:443
2021/03/13 18:32:56 [Info] github.com/v2fly/v2ray-core/v4/transport/internet/udp: failed to handle UDP input > EOF
2021/03/13 18:33:04 [Info] github.com/v2fly/v2ray-core/v4/common/mux: failed to read metadata > io: read/write on closed pipe
2021/03/13 18:33:05 [Info] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: connection ends > context canceled
2021/03/13 18:40:56 [Info] [2295777139] github.com/v2fly/v2ray-core/v4/proxy/http: request to Method [CONNECT] Host [us.lijinglin.dev:443] with URL [//us.lijinglin.dev:443]
2021/03/13 18:40:56 [Info] [2295777139] github.com/v2fly/v2ray-core/v4/app/dispatcher: sniffed domain: us.lijinglin.dev
2021/03/13 18:40:56 [Info] github.com/v2fly/v2ray-core/v4/transport/internet/udp: establishing new connection for udp:<IP_ADDRESS>:53
2021/03/13 18:40:56 [Info] github.com/v2fly/v2ray-core/v4/app/dispatcher: taking detour [h2] for [udp:<IP_ADDRESS>:53]
2021/03/13 18:40:56 [Info] github.com/v2fly/v2ray-core/v4/common/mux: dispatching request to udp:<IP_ADDRESS>:53
2021/03/13 18:40:56 [Info] [2295777139] github.com/v2fly/v2ray-core/v4/app/dispatcher: taking detour [h2] for [tcp:us.lijinglin.dev:443]
2021/03/13 18:40:56 [Info] [2295777139] github.com/v2fly/v2ray-core/v4/common/mux: dispatching request to tcp:us.lijinglin.dev:443
2021/03/13 18:40:58 [Warning] failed to handler mux client connection > github.com/v2fly/v2ray-core/v4/proxy/vmess/outbound: failed to find an available destination > github.com/v2fly/v2ray-core/v4/common/retry: [github.com/v2fly/v2ray-core/v4/transport/internet/http: failed to dial to tcp:us.lijinglin.dev:443 > Put "https://us.lijinglin.dev:443/adf2af88-8a8c-351f-cd67-be9254d03cc2": dial tcp: operation was canceled] > github.com/v2fly/v2ray-core/v4/common/retry: all retry attempts failed
2021/03/13 18:40:58 [Info] github.com/v2fly/v2ray-core/v4/common/mux: failed to read metadata > io: read/write on closed pipe
2021/03/13 18:40:58 [Info] github.com/v2fly/v2ray-core/v4/transport/internet/udp: failed to handle UDP input > EOF
2021/03/13 18:40:59 [Info] [2295777139] github.com/v2fly/v2ray-core/v4/app/proxyman/inbound: connection ends > github.com/v2fly/v2ray-core/v4/proxy/http: connection ends > context canceled
2021/03/13 18:40:59 [Info] [2295777139] github.com/v2fly/v2ray-core/v4/common/mux: failed to fetch all input > io: read/write on closed pipe

只有这一次更改 https://github.com/v2fly/v2ray-core/commit/405a051c50e032abc092d01f3a50adeeb585401d

只有这一次更改 405a051

本地 revert 这个 commit 后编了个包，问题解决

补一个现象帮助排查原因，outbounds 有持续的流量时一般出现几率很小，没有流量时运行一段时间(十分钟以上)必现

感觉和我之前在XRay上遇到的问题有点像
https://github.com/XTLS/Xray-core/issues/289

更新到 4.39.2 这个问题又复现了，看代码是又改回来了？
https://github.com/v2fly/v2ray-core/commit/7b721e1a6f8d0dc678cd87084d5564baab289496#diff-2bdea65f8b41dd985c31cdffbb5c802d3569c2c0a5285b1fd2be87aa8384958a


Retrieve secrets from Key Vault is failing

Hi Team,
I've configured Azure Load Test a test to pull secrets from Key Vault, however it is failing with: Unable to find the given secret Correlation ID: GUID
I performed  the following steps to enable this capability:

added secrets to KV and added parameters to to the test -How to parameterize load tests
Updated my JMX to have User Variable using __GetSecret to pull the secrets Use secrets in Apache JMeter
A system MSI is in place for the test and it has been granted Get permissions for Secrets - Grant access to Azure Key Vault

I review the AzureActivity and AzureLoadTestingOperation logs but didn't find any additional information.
My issue looks like this one, but it was resolved sometime back - #25
Is this a new occurrence? Are there additional logs I can enable/review?
Eric
AB#1659304

@EricHunsberger Can you please share the test run ID? This will help us debug the issue.
Thank you.

@Nagarjuna-Vipparthi this is the correlation ID from the error - 51aad157-c189-459d-8d6a-e3c076bdd012

Having this exact issue. Any info that can be shared on resolving the above appreciated.

So in my case I changed what I called the user defined variable secret. I originally used the same name as the KV secret entry, which included dashes. I simplified this name to "functionKey" and that seemed to resolve this error.
However I then hit another problem - The provided Key Vault reference identity does not have required permission(s) to access the Key Vault. I'm wondering is this problem due to cross-subscription access? We use a single KeyVault instance in our PROD subscription - can get this to work fine with AKS and APIM services, but maybe Azure Load Test Preview doesn't like the fact that the Azure Load Test resource is in a different Subscription to KeyVault - AAD is obviously shared across all our subscriptions.

@Nagarjuna-Vipparthi this is the correlation ID from the error - 51aad157-c189-459d-8d6a-e3c076bdd012

@EricHunsberger Can you please check and confirm if you used the same managed identity for the test run and Key vault access? We see an 'Unauthorized Access to keyvault' error message suggesting that the provided Managed Identity does not have permission to access the Key Vault / Secret.

@cathalmchale Can you please confirm if in the test creation, you have selected the managed identity that has access to the Key Vault? You can find this option under the 'Parameters' tab

Hi @Nagarjuna-Vipparthi I've tried with both System assigned and User-assigned and ensured that these added to the Access Policy in Key Vault. However, I think the issue is probably the fact that our Key Vault isn't public. It's setup like:

So it's likely that the other Azure Services can access via policies and assigned identities etc. because they are also within a trusted vnet. I'll test this theory by setting up a new temporary Key Vault with public access for all networks and associate the same managed identities - should  be able to observe one Key Vault succeed and the other fail in the Load Test if it's the root.

I have the Test (Catalogpage) configured with a System-assigned identity and the "catalogpage" application has Get permissions on the KeyVault.
My KeyVault Networking is set up very much like Cathal's.

Allow public access from specific virtual networks and IP Addresses
our internal virtual subnets are configured
Allow trusted Microsoft services to bypass this firewall is enabled

Hi @EricHunsberger , I spent a bit of time root causing this one and it's definitely to do with the non-public KeyVault, rather than there being anything wrong with the Identity assignment or KeyVault access policy. So I went ahead and logged it as a more specific bug #117
Be good if you could comment on that bug as well as sounds like we've the same root cause, manifesting itself with the same error message.
I'm hoping that this will be something that Microsoft will look to resolve when the feature comes out of Preview. Afterall, we're only trying to follow some best practices in our KeyVault setup!
For now I've chosen to setup a public "dev" KeyVault that I'll store a few secrets that are important and required by the load tests. Not ideal and complicates "secret recycling" which we're trying to get better at. Also the public KeyVault is going to show up in our security scans as an issue, but we'll try justify it's limited scope and move forward for now until another resolution is possible.

Hi Cathal,
Thanks for the update. I'll add my comments to the other issue.
Unfortunately I can't switch my access policy.
Eric

From: Cathal McHale @.>
Sent: Monday, November 7, 2022 3:26 PM
To: microsoft/azure-load-testing @.>
Cc: Hunsberger, Eric @.>; Mention @.>
Subject: [EXT] Re: [microsoft/azure-load-testing] Retrieve secrets from Key Vault is failing (Issue #112)
Hi @EricHunsbergerhttps://github.com/EricHunsberger , I spent a bit of time root causing this one and it's definitely to do with the non-public KeyVault, rather than there being anything wrong with the Identity assignment or KeyVault access policy. So I went ahead and logged it as a more specific bug #117https://github.com/microsoft/azure-load-testing/issues/117
Be good if you could comment on that bug as well as sounds like we've the same root cause, manifesting itself with the same error message.
I'm hoping that this will be something that Microsoft will look to resolve when the feature comes out of Preview. Afterall, we're only trying to follow some best practices in our KeyVault setup!
For now I've chosen to setup a public "dev" KeyVault that I'll store a few secrets that are important and required by the load tests. Not ideal and complicates "secret recycling" which we're trying to get better at. Also the public KeyVault is going to show up in our security scans as an issue, but we'll try justify it's limited scope and move forward for now until another resolution is possible.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/azure-load-testing/issues/112#issuecomment-1306146522, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQ5RMWOFY5LPFNYYYRSES33WHFQXNANCNFSM6AAAAAARRHU5ZM.
You are receiving this because you were mentioned.Message ID: @.***>
This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.
Deloitte refers to a Deloitte member firm, one of its related entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a separate legal entity and a member of DTTL. DTTL does not provide services to clients. Please see www.deloitte.com/about to learn more.
v.E.1

Hi @EricHunsberger .. we have added this to our backlog for now and will report back once it is implemented.


connection fails with mqtt->setUseLts(false);

when mqtt->setUseLts(true); flag in row 182 in esp8266_mqtt.h is set to false (mqtt->setUseLts(false)), no connection can be established although "connect!" message is received at start.

Thanks for reporting this, I'll take a look. What port are you using (8883 or 443)? Also, I believe that the root certificate may need to be different when you change the server.

tried both ports without success. used the same certificates as for tls though, which one would be correct?

The problem was the certificate. Connection worked with "GlobalSign Root CA - R2".
For some non LTS method is faster by about 2 seconds, which is very important when battery saving is priority.

@stasysdr Thank you for reporting this!


Remove Effect by Origin

Is your feature request related to a problem? Please describe.
RAW, multiple status effect durations can be layered, ex: A player can be caught in a Web (applying Restrained), and separately they can be Entangled (also applying Restrained). In a DM driven-game it is simple enough for the DM to know that both saving throws need to be made before they lift the Restrained condition, but in a "video game"-mode highly automated game, there are benefits to actually applying the Restrained effect twice and differentiating based on effect origin.
The macro driving the automation for Web will want to remove only the Restrained condition it applied. Similarly, the Entangled macro will only want to remove its Restrained condition. If the DM intervened and manually removed one or both conditions, the macros will want to be handle that state correctly and as expected.
Describe the solution you'd like
The convenience API, game.dfreds.effectInterface.removeEffect, take an optional string parameter, origin. The named effect will only be removed if it is present on the actor from the matching origin. If the origin parameter is undefined, the current behavior applies.
Describe alternatives you've considered
This functionality can be implemented manually fairly easily, searching and removing the active effect, or by using other modules such as warpgate-based mutations. This is a convenience API, this feature is being requested for convenience.
Alternatively, the spells could apply their own conditions, "Web" and "Entangled" that have all the AEs of Restrained but different names, making this request unnecessary. This is non-ideal, as players are typically familiar with standard status effects but may not be familiar with every spell and its effects. A player who sees two Restraineds understands at a glance what that means, a player who sees an "Entangled" status icon pop up might have to ask what that means.

Added in next release


[5.0] Runtime: Make getTypeByMangledNameIn(Context|Environment) a public entry point.

This can be used by compiler-generated code as a size optimization for metadata access, using a
mangled name instead of possibly many open-coded metadata calls. It can also allow reflection
libraries outside of the standard library to turn type reference strings into in-process metadata
pointers in a robust way. rdar://problem/46451849
This is an additive ABI change. It is not needed for convergence.

@swift-ci Please test


Patator Support

Dear x90skysn3k,
An effort was made for the additional support of the patator bruteforcer in brutespray which stems from a personal project. Please review the changes I've made and let me know about your thoughts.
Regards.

we could make the default medusa, then add support for patator and create an option for it, if it works good and people like it we could eventually change it.. I've never used patator, so i'll have to do some testing, but looks good.. i'll be testing this 👍

@metalcorpe please create a new branch in your fork of brutespray to submit a PR.
git checkout -b <BRANCH_NAME>
git push <your_fork_remote> <BRANCH_NAME>

When you open a new PR, please open it against brutespray/alpha.
Closing this PR.


add support @sealed()  @enumerable()  and such operation decorator to direct translate it

✅ Viability Checklist

My suggestion meets these guidelines:

[ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[ ] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
since ES2015 with class support ,  the default state for get set and method in class is not enumerable: true, and that cause a problem for JSON.stringfy  because  get property will not be serialized .
and those operation decorator  such like @enumerable @sealed  can be direct translate to normal javascript without
decorator and  metadata support.
class Foo{
    @enumerable()
   get str(){
     return 'foo'
   }
}

// translate to

class Foo{

   get str(){
     return 'foo'
   }
}
Object.getOwnPropertyDescriptor(Foo,'str')!.enumerable = true;

📃 Motivating Example

the default state for get set in class is not enumerable: true
💻 Use Cases
in uni-app for mini-program , it use JSON.stringfy to remap the object member , and the class get set  would not be serialized

Baking this in to TS as a built-in would be in direct conflict with the ongoing TC39 decorator proposals.
I believe you could write in user space today with experimental decorators, so there's no need for TS to do this itself.

Baking this in to TS as a built-in would be in direct conflict with the ongoing TC39 decorator proposals.
I believe you could write in user space today with experimental decorators, so there's no need for TS to do this itself.

@RyanCavanaugh   may I ask what is the stage of decorator proposals (and how many stage are their)?   and where I can find the detail ?

@RyanCavanaugh   may I ask what is the stage of decorator proposals (and how many stage are their)?   and where I can find the detail ?

@RyanCavanaugh   may I ask what is the stage of decorator proposals (and how many stage are their)?   and where I can find the detail ?

@RyanCavanaugh   may I ask what is the stage of decorator proposals (and how many stage are their)?   and where I can find the detail ?

@John0King https://github.com/tc39/proposal-decorators

@John0King https://github.com/tc39/proposal-decorators


method #element should return an element

this fixes #20

bump, any chances this can be merged and a new gem release performed?

I'm afraid we can't merge this as the actual problem is not with this code, but the fact is that the WSDL that you'd like to use doesn't seem to be properly supported by lolsoap (as explained in #20). We'd welcome a PR for WSDL parser to support your WSDL though.

Regardless of my original problem, this PR fixes the object type returned by the #element method. It currently returns type which makes no sense.
btw I don't know if the WSDL is correct or not [1]. Just have to use the API and I don't have control over the software I need to use. With this PR most everything starts to work and the method starts to make sense returning proper object type.
[1] I'm actually pretty sure WSDL is not entirely correct because found a call that I don't see description of (even in SoapUI) but performing that call does work.

Again, I didn't explain this well, I'm sorry.
A NullType object is returned when we try to access an element that lolsoap's WSDL parser knows nothing about. Perhaps it doesn't make sense to return NullType.new in NullType#element, it should probably just raise an error as we can't know anything about elements of an uknown type.
Making it return a NullElement would be like pretending that everything is fine and making it seem that we can rely on a WSDL that we can't properly parse. It could cause other unexpected issues elsewhere.
TLDR: the current code is confusing, but I think that merging this fix can cause even more confusion and that's why I'm reluctant to do it.
As suggested in #20 I think that not using response.body_hash and just parsing response.body using xpath is probably a better workaround.
Hope this makes sense.

Hey, I have one question, I have a wsdl private, is it easy to change the link http://example.com/stockquote.wsdl for   http://MY_WSDL.wsdl  ?

I don't fully agree with the above assessment. For me hash builder should just traverse elements and get the strings no matter if type is known or unknown. Just much more convenient and low risk IMO.  And even if I figure, as I probably mentioned, there might still be non-described elements by WSDL as it seems to me looking with SoapUI.
So my proposal to project owners is to accept the patches to make unknown elements still allow to be converted to hash elements. My dirty solution is monkey patching NullElement like this:
class LolSoap::WSDL
  class NullType

    # https://github.com/loco2/lolsoap/pull/21
    def element(name)
      NullElement.new
    end

    def element_prefix(name)
        self.prefix
    end

    def sub_type(name)
        element(name).type
    end

    def has_attribute?(name)
        false
    end
  end
end

Turned out a few more things were needed than I thought originally. Leaving to the discretion of project owners and the reader to decide what to do with the information above (if anything at all).
Cheers.


Fix periodicity bug

We had a bug when running multiple celery send_event_notification_message_task tasks that would throw attached to a different loop. The error was caused by asyncio.run(...) call that would create a new event loop for each task execution which led to celery worker have multiple event loops resulting in attached to a different loop error.
Fixed it using asyncio.get_event_loop() call and then called run_until_complete on it therefore utilizing only one event loop.
Also fixed rabbitmq not having persistent queue resulting in event notification messages not being sent after broker container restart. Had to specify hostname for rabbitmq container.
docker-library/rabbitmq#106

a minor improve to Makefile allowing to show logs and open shell not just for bot container but for any


Binary error while loading shared libraries: libssl.so.1.0.0

I downloaded the binary release, on Ubuntu 18.04 server, and on running ./wallet713 I got this error:
./wallet713: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

This should be sorted out in v1.0.1 release.

After downloading and running new binary release I got this error:
:~/wallet713$ ./wallet713
./wallet713: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
Press any key to continue...

I am on  Debian GNU/Linux 9.4 (stretch)
kernel 4.9.0-4-amd64
openssl version in debian is:
:~/wallet713$ apt-cache policy openssl
openssl:
  Installed: 1.1.0f-3+deb9u2
  Candidate: 1.1.0f-3+deb9u2

Updated debian to latest version, but unfortunately no change for wallet713, the same error message.
debian  9.7
kernel 4.9.0-4-amd64
openssl: Installed: 1.1.0j-1~deb9
```u1

Getting this error again on Fedora 29 for version 1.1.0.

Getting this error still.

I want to believe that we finally, once and for all, have put this issue to bed.
Try the new streamlined download and install experience here:
https://wallet.713.mw/install
Let me know if it works. 🤺

@lehnberg
still not working
[user@pc ~]$ curl https://wallet.713.mw/install.sh -sSf | sh
\033[1;34mWallet713 binary installer 1.0\033[0m
\033[1;30m
Configuration: [amd64]
Location:      [https://github.com/vault713/wallet713/releases/download/v1.1.1/wallet713-v1.1.1-508990898-linux-amd64.tgz]
Directory:     [/home/user/bin]
\033[0m
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   633    0   633    0     0    909      0 --:--:-- --:--:-- --:--:--   908
100 5661k  100 5661k    0     0   208k      0  0:00:27  0:00:27 --:--:--  260k
\033[0;32m
Installation completed successfully.
$ wallet713 --version
/home/user/bin/wallet713: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
\nRun 'wallet713' from the command line to open the wallet
\033[0m

Let me know if it works.

I don't know but I would expect you tested it and at least confirmed it works in a default distro install so I can expect something.

@jmliz thanks for reporting. We did indeed do several tests, but not on Fedora 29 specifically. Investigating.

wallet713
wallet713: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
i got this problem when i updated to ubuntu 19.04.
i could build it so got it working that way.

@urza @jmliz @fueleh Would you be willing to test out the latest binary? I think SSL error should be fixed now, finally.

@urza @jmliz @fueleh Would you be willing to test out the latest binary? I think SSL error should be fixed now, finally.

nope
curl https://wallet.713.mw/install.sh -sSf | sh
then
wallet713
wallet713: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

@jaspervdm
works fine for me on Ubuntu 18.04
I no longer have the debian box though..

Given that we have received no new reports of broken binaries for a while, I am assuming the fixes we implemented some time ago were sufficient.


fuse volume permission denied

i have a fuse volume in docker using https://github.com/vieux/docker-volume-sshfs
when i receive email i have a permission problem, how to fix it?
note:
i using fuse with docker plugin and fuse sshfs
error logs:
Jun 14 09:29:26 72d59c8123 postfix/smtp[1125]: 285C0285A22<EMAIL_ADDRESS>relay=<IP_ADDRESS>[<IP_ADDRESS>]:10024, delay=1.6, delays=0.58/0.01/0.01/0.98, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[<IP_ADDRESS>]:10025): 250 2.0.0 Ok: queued as 7DDD8285A2D)
Jun 14 09:29:26 72d59c8123 postfix/qmgr[1016]: 285C0285A22: removed
Jun 14 09:29:45 72d59c8123 dovecot: ssl-params: SSL parameters regeneration completed
Jun 14 09:29:45 72d59c8123 dovecot: lmtp(1134): Connect from local
Jun 14 09:29:45 72d59c8123 dovecot: lmtp(1134, test@test.com): Error: User initialization failed: Namespace '': stat(/var/mail/test.com/test) failed: Permission denied (euid=5000(docker) egid=5000(docker) stat(/var/mail/test.com/test) failed: Permission denied, dir owned by 0:0 mode=0755)
Jun 14 09:29:45 72d59c8123 dovecot: lmtp(1134): Disconnect from local: Successful quit
Jun 14 09:29:45 72d59c8123 postfix/lmtp[1133]: 7DDD8285A2D<EMAIL_ADDRESS>relay=72d59c8123.test.com[/var/run/dovecot/lmtp], delay=19, delays=0.01/0.01/19/0, dsn=4.3.0, status=deferred (host 72d59c8123.test.com[/var/run/dovecot/lmtp] said: 451 4.3.0<EMAIL_ADDRESS>Temporary internal error (in reply to end of DATA command))

Not sure this will work properly. You need to be able to create files with the uid 5000

This issue was closed due to one or more of the following reasons:

Age
Contributor inactivity
The issue seems to be resolved

If you think this happened by accident, or feel like this issue was not actually resolved, please feel free to re-open it. If there is an issue you could resolve in the meantime, please open a PR based on the current master branch so we can review it.


Change White Matter removal process for electrode plotting

Change the electrode parcellation label picking process from current implementation to match the MATLAB implementation.

Current intended MATLAB implementation: https://github.com/coganlab/MATLAB-env/issues/7

Current label picking logic implemented here:
https://github.com/coganlab/IEEG_Pipelines/blob/157bb0843f2ed7864683b0fc1458c4288fa433e8/ieeg/viz/mri.py#L343-L371


Remember last opened project

Please add a setting to save the ID of the last opened project.
When the user starts the program, it is necessary to automatically load the project data.
Excluding cases when recovery is triggered when the program crashes.

Implemented in v1.1.


Add OpenSCAP scan to supported features mixin

OpenSCAP scan is an action similar to Smart State Analysis,
but scanning security vulnerabilities.
Adding it to SupportsFeature mixin while making it supported in
OpenStack provider.

@moolitayer how do you do this in containerland? Is by default everything openscap enabled? Would it make sense for you to use the support feature mixin as well?

When a user scans a ContainerImage, we always run both an OpenSCAP scan & and a package scan[1] @durandom. We don't need to make that distinction ATM.
[1] https://github.com/ManageIQ/manageiq-providers-kubernetes/blob/0a9976a0a8491a4fca88d724c163ad73fb40e9ec/spec/models/manageiq/providers/kubernetes/container_manager/scanning/job_spec.rb

@aufi do you already have a corresponding PR in the UI and openstack?

@durandom Not yet, should I create a placeholder WIP PR for reference in OpenStack repo?

@moolitayer once this is merged, you might want to add supports :open_scap to the container base models or if you are using subclasses to the subclasses


Feature Request: Recognize BunsenLabs Openbox DE

Description
Currently neofetch detects the BunsenLabs DE as Xfce. While it's true that BL uses xfce4-power-manager, xfce4-notifyd and xfconfd in it's OOTB experience, it is not an Xfce4 desktop, there is no settings-manager or xfdesktop4 session running.
It would be preferable if neofetch could display "DE: None" or "DE: BunsenLabs Openbox" as the DE.
Thanks for your great work, and for considering this feature.
:D
Neofetch version
neofetch:
  Installed: 6.0.0-2
  Candidate: 6.0.0-2
  Version table:
 *** 6.0.0-2 500
        500 https://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

Screenshot
https://cdn.scrot.moe/images/2019/04/14/Screenshot_2019-04-14_14-30-15.png
Config file
default
Verbose log
https://pastebin.com/j7R3CHhA

What's the output of $XDG_CURRENT_DESKTOP? Maybe one of xfce4-power-manager, xfce4-notifyd and xfconfd changed it to Xfce causing neofetch to detect it.

Sorry for the delayed response...
bash: XFCE: command not found

However, the is no Xfce.desktop file in /usr/share/applications, but there is an Openbox one.
And since my awesome wm session is properly detected and displayed by neofetch, and I'm running xfce4-power-manager and therefore also xconfd there, I gues the culprit is xfce4-notifyd, but that seems pretty weird.
Any more info I can give, please let me know. Thanks for looking into this!

Oh, for the awesome session...
roy@TyrellCorp:~$

This isn't a neofetch issue as $XDG_CURRENT_DESKTOP reports XFCE. "Working as intended".

Thanks for your responses here, it's solved the issue. BL sets the environment to XFCE in ~/.config/openbox/environment to solve some xdg-open issues, I had forgotten all about it. I can override it there if needed for a prettier screenshot. :p
Cheers.


Passing dynamic data from template to components that use :items

Environment

Operating System: Windows_NT
Node Version:     v20.18.0
Nuxt Version:     3.13.2
CLI Version:      3.14.0
Nitro Version:    2.9.7
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      -
Runtime Modules:  -
Build Modules:    -

Version
v3.0.0-alpha.6
Reproduction
Cannot use v3 on stackblitz so no repo.
Description
Not a v3 specific thing neither a problem but a question. I couldn't find any guide on this.
Is it currently possible to pass dynamic data to components like https://ui3.nuxt.dev/components/navigation-menu from template ?
Say, we have a v-for with 'NavigationMenu' inside and I want to use the individual id from v-for to link a page like '/products/s53-32ef52f:

<template>

      <UNavigationMenu orientation="vertical" :items="actionItems" />

</template>

Only way i can think of is:
:items="[
          [
            {
              label: $t('products.table.actions.edit'),
              icon: 'ph:pencil',
              to: `/products/${product.id}/edit`,
            },
          ],
        ]"

Is this the way to do this?
Additional context
No response
Logs
No response

This v-for creates multiple NavigationMenus. Is that really what you want?
I think you need just one Navigation Menu with a corresponding items array. You could map the products array within the script setup and create your items array which is then passed into the navigation menu.
Not tested

<UNavigationMenu orientation="vertical" :items="items" />

@malte-baumann Uh sorry I wasn't clear enough. It is more like when using for example click event and getting that one only product.
So index may be different for example with sorting etc.