GH Actions: upgrade ubuntu version

https://github.blog/changelog/2022-08-09-github-actions-ubuntu-22-04-is-now-generally-available-on-github-hosted-runners/

switch to 22.04 for testing
switch to ubuntu-latest for merge

Coverage remained the same at 86.815% when pulling d40ad13a2618697fd82f4cd52348b8bb9af88fc0 on actions-upgrade-ubuntu-version into 6ed545a3ea9153c4f1632b242bd6bdaf488240e5 on main.

as a sidenote: while reading the linked docs, i just stumbled across the fact that setup-python includes support for caching poetry dependencies, so we could get rid of our own caching solution as it already caused problems in the past.
https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#caching-packages

and another sidenote: the runners also include a postgres and a mysql service, so we could also use the pre-installed one instead of our own solution
https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md#databases


Expand access to the email scope

The email scope requests the user's email if available. Currently this is only available to a whitelisted group of apps. We should expand this to all apps.
To do this, we need to make sure that users are clearly informed about this request and have the option to opt out.

I think this feature would make it easier for developers and product managers to integrate Login with Blockstack in their apps.
Also, it will definitely help making the login process similar to what popular oAuth connectors offer (like Google and Facebook).

@larrysalibra this would be very helpful for Prism, which Stefano is the engineer for, to have a cleaner onboarding flow. How much engineering effort is there to do this?

Yeah this feature would be huge.

I've created a pull request to blockstack browser that removes the app whitelist we had previously. https://github.com/blockstack/blockstack-browser/pull/1220

I'm writing a docusign clone app and email consent would be huge! right now i have to write my own hack to index each users email address

@ntheile sorry for not closing out this issue earlier - we shipped the email scope a couple months ago (see the merged pull request above).


GetBucketPolicy always returns nil Policy

I'm trying to use GetBucketPolicy, but even if a bucket has a policy, the GetBucketPolicyOutput Policy field seems to be nil. I've verified that the HTTP response contains the policy.
Reproduction and output are in this gist: https://gist.github.com/justincampbell/1a55a043bd926cbba0dc

HI @justincampbell thanks for reporting this. Looks this issue is related to the response coming back as the policy's JSON format, but the SDK's S3 unmarshaller is expecting XML. Need to dig a bit deeper but looks like we may just need a custom unmarshaller for the GetBucketPolicy operation.

@justincampbell You should now be able to retrieve the bucket policies using the SDK. Let us know if you run into any other issues.

Thanks! It's now working.


tensorflow: streamline the installation rules a bit

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please test tensorflow


FileNotFoundException in TaskService.GetTask(taskName);

Hi!

it.s common practice for methods like GetTask(taskName);
to return NULL when task wasn't found because it's expected value for situation when task is not available.

Thank's
Originally posted: 2009-09-23T09:17:17

            var exisingTask = ts.GetTask(taskName);
            if (exisingTask != null)
            {
                ts.RootFolder.DeleteTask(taskName);
            }

Originally posted: 2009-09-23T09:17:50

I also found this problem when I tried my application on Windows XP
Originally posted: 2009-09-23T18:33:22

This is the error: (as taskPath I used ---> @""+taskName <----   theTask = backupTaskService.GetTask(@""+nameOfTask);
No problems with Windows Vista/7
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.IO.FileNotFoundException: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
at Microsoft.Win32.TaskScheduler.V1Interop.ITaskScheduler.Activate(String Name, Guid& riid)
at Microsoft.Win32.TaskScheduler.TaskService.GetTask(ITaskScheduler iSvc, String name)
at Microsoft.Win32.TaskScheduler.TaskService.GetTask(String taskPath)
at MailBrowserBackup.ScheduleClass.getTriggerProperties()
at MailBrowserBackup.ScheduleWnd..ctor()
at MailBrowserBackup.MainWnd.schedulerBtn_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Originally posted: 2009-09-23T18:45:21

This issue only affected tasks under the V1 engine that are not found as named. An exception was thrown and not handled. Line 132 of TaskService.cs was modified to handle the exception so that GetTask will always return null if the specified task is not found.
Originally posted: 2009-09-29T21:14:05


Events → BatchMode → Flush doesn't block and wait

Description
The documentation for the Events.Flush method says:

Flush gives the user a way to manually flush the queue in the foreground. This is also used by watchdog when the timer expires.

I expect foreground to be synonymous with block and wait, and the client doesn't appear to be doing that. This is the culmination of research that was originally discussed in #464.
Go Version
go version go1.15.2 darwin/amd64

Current behavior
Reading thousands of records from one system, and pushing them into New Relic via pkg/events in batch mode. Code is very similar to what was posted in #464, but essentially boils down to something like this:
(I've stripped out some event handling and logging code, so there may be some phantom variables here.)
func main() {
	ctx := context.Background()

	cfg := config.New()
	cfg.InsightsInsertKey = os.Getenv("NEWRELIC_INSIGHTS_INSERT")
	cfg.Compression = config.Compression.Gzip
	cfg.LogLevel = "trace"

	client := events.New(cfg)
	logger := cfg.GetLogger()

	// Start batch events mode
	if err := client.BatchMode(
		ctx,
		nrAccountID,
		events.BatchConfigTimeout(batchTimeout),
	); err != nil {
		log.Fatalln("error starting batch mode:", err)
	}

	// Spawn goroutines...
	wgRawData.Add(1)
	go profileRaw(rawChannel, &client, &cfg)

	// Wait for goroutines to return...
	go func() {
		wgRawData.Wait()
		close(rawChannel)
	}()

	for rawData := range rawChannel {
		spew.Dump(rawData)
	}

	// Force-flush the events when we're done with this batch of data so that
	// the function ends and returns instead of listening indefinitely.
	if err := client.Flush(); err != nil {
		logger.Error(fmt.Sprintf("error flushing event queue: %s", err.Error()))
	}

	logger.Info("==> Events instructed to flush.")
}

// Leverages Go channels to execute the processing concurrently.
func profileRaw(c chan Response, client *events.Events, cfg *config.Config) {
	// Prepare to close the channel
	defer wgRawData.Done()

	ctx := context.Background()
	logger := cfg.GetLogger()

	logger.Info("==> Kicking off the profiler...")

	// Run the profiler
	output, ok := profiler(profilerDuration)
	if !ok {
		logger.Error("Profiler function failed.")
		c <- resp
	}

	logger.Info("==> Parsing profiler data...")

	payloads := strings.Split(output, "\n\n")

	logger.Info("==> Sending data chunks to New Relic as events...")

	for i := range payloads {
		payload := payloads[i]

		// Read the JSON into the appropriate Go struct
		err = json.Unmarshal([]byte(payload), &event)
		if err != nil {
			logger.Error(fmt.Sprintf("[] error unmarshaling JSON into struct: %s %s", err.Error(), payload))
			break
		}

		// ...do stuff to transform raw profiler event data into a flattened
		// structure that the New Relic Events API wants...

		// Queue a custom event
		if err := client.EnqueueEvent(ctx, flatEvent); err != nil {
			logger.Error(fmt.Sprintf("error posting custom event: %s", err.Error()))
		}
	}

	logger.Info("==> Sending events completed.")

	// Return data to the channel, closing it
	c <- resp
}

What happens is that client.Flush() isn't preventing the program from ending, so main() exits before the queue flushes (or, more accurately, even starts).
Expected behavior
My expectation is that client.Flush() should block and wait — preventing main() from exiting until the flushed events have responded successfully (or at least have been sent in the first place).
Steps To Reproduce

Create a new events client.
Put it into batch mode.
Set it to flush every second.
Enqueue a few thousand event messages.
Trigger a flush.
Program ends.

Additional Context
I was seeing cases where sometimes events made it, and other times they did not. The difference appeared to be related to which log level I was setting on the client. Once I narrowed-down the variables in the puzzle, I discovered that it wasn't the log level so much as the time it took for those log levels to write data to stdout/stderr.

debug and trace wrote a lot more data to stdout/stderr, which slowed-down the program enough to allow the goroutines to complete.

info wrote less data, enabling the program to run faster, and the goroutines didn't have enough time to finish (or even start).

A workaround has been to sleep at the end of the main() function.
time.Sleep(5 * time.Second)

But what this means is that it always ends up sleeping either too long or not long enough. Too long means that I'm missing out on other live events while I'm waiting for the program to finish sleeping before listening again. Too short means that some events I've read aren't making their way to the Events API.
Ideally, the client should intrinsically understand what it needs to block for, then stop blocking once the queue flushing has completed (for whatever definition of "completed" is appropriate — request has been sent, or response has been received).
References or Related Issues

#464

Thank you for raising the issue.  It looks to me what we need is a new blocking Shutdown() method that will wait until all the messages are sent before returning, and prevent new messages from entering the buffer.  Looks like the Flush() method only write a control message to the channel, which triggers the listener routine to perform the actual sending.  But this is not quite right either, since the grabAndConsumeEvents() method also spawns a go routine to perform the actual sending.
The batchWorker is maintaining some state about the count, which I'm not sure how to handle if the flusher logic were moved out.  Too, a Flush() doesn't stop the execution, so even while a flush is happening, it looks like more events could be written to the buffer, which is probably less than desirable.  So perhaps if we took the route of writing a new Shutdown() method, this could terminate the context, but that might not be right since the context is passed to batch worker from the caller.
Perhaps a combination of sync.Wait usage within grabAndConsumeEvents and copying the flush logic into a shutdown method could help.

I wonder too, if we might be able to leverage the context object to close down the rest of the system while the post completes.  I don't expect to be able to look into this in the near term though.

@skyzyx This looks like a documentation issue as Flush was meant to allow a lever to manually initiate sending data, but not block/wait.  (The initial use-cases for this were all services, and not expected to shutdown).  Adding logic as @zlesnr suggests to a new func seems reasonable.

Bump.

Hi @skyzyx
Were you able to work around this or is it still an active issue?


⚠ SceneTime has degraded performance

In 0f7ee58, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1287 ms

Resolved: SceneTime performance has improved in 17ff827 after 6 minutes.


Add support for multi Repo

Please add support for multi repos via allowing the base package of a repository to have Information about the superpackage also serialized.
Use Case:
For big projects you have independend parts. So each independend part gets its own git repository.
In the source system the packages of these individual repositories are neatly organized in subpackages.
In order for the target sytem to have this nested package structure it is currently necessary to create packages with the corresponding superpackages per hand.
This should be automated.

Yes, it's a nice-to-have feature. There's some effort required to implement this so low priority.
You could create a repo for the main package structure manually (clone https://github.com/abapGit-tests/DEVC_main_sub/tree/main/src). Then deploy this repo first to get all packages into the target system, and remove the repo afterwards (without uninstalling objects, obviously). Now you can bring in all the parts.


Where can I find the old UI?

The instructions on how to install the old UI are there, but where is the code?

@dai-mk are you looking for this ? https://github.com/Hygieia/Hygieia/tree/master/UI


scylla_node: _update_jmx_pid: don't throw exception if scylla-jmx.pid not found

This method is called from node.stop() and we've seen cases where
this file was not found.
Move the call to a more specific place where we want to kill scylla-jmx
And since this is not critical at this point do not throw exception
if the file not found (we should have the pid from when starting
scylla-jmx).
See cql_tests/TruncateTester/truncate_after_restart_test:
Note that the exception message is misleading as we're stopping the node and the exception mentions starting node scylla-jmx, I guess for historical reasons.
Problem starting node node2 scylla-jmx due to [Errno 2] No such file or directory: '/jenkins/workspace/scylla-master/manual-and-scheduled-tests/byo_build_tests_dtest/scylla/.dtest/dtest-ENWvf2/test/node2/scylla-jmx.pid'

@bhalevy  - I don't understand how this can happen - I'll try to look more - ping me if no response in 2 days

@slivne ping

@slivne ping

Now that I've merge the other on, you need to resolve conflict

Now that I've merge the other on, you need to resolve conflict

@fruch done


Integration Test - Release - 2022/03/08 09:38:40

Auto create for integration test. IssueCommandFlow

#pri1

Just type '#pri3'

#pri2

#pri3

#assign PRMergerTest1

#assign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#reassign PRMergerTest2

#reassign NonAllowedUser

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#please-close

GitHub user PRMergerTest1 has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

#unassign PRMergerTest1

#unassign NonAllowedUser


Publish a new release?

There have been A LOT of changes since the last release.

Thanks @jonhealy1 I'll be releasing 2.4.0 tomorrow once #441 is finished!

Yes! Thanks. Changes look great

https://github.com/stac-utils/stac-fastapi/releases/tag/2.4.0

🙏 Thanks @geospatial-jeff


Buttons for additional windows

I work with JAVA applets that run in full window mode. This is the correct behavior.
JAVA applets also have a virtual keyboard mechanism, which we can enable from the options menu. In the docker container it looks like this: https://gyazo.com/caeb39e001ae333971659e55997ee789
I would like to include navigation buttons for additional windows to make it look like this: https://gyazo.com/e634d47f24c03cf4920a88469d1aa76a
Is it possible?

I solved this by adding a simple script:
sed -i 's/<decor>no/<decor>yes/' /etc/X11/openbox/rc.xml
openbox --restart

Perhaps there is a better solution that you can recommend ;)

Looks like you need to properly identify the main window.  See:
https://github.com/jlesage/docker-baseimage-gui#maximizing-only-the-main-window

Unfortunately, this solution does not work. Both windows (main and virtual keyboard) have exactly the same parameters (name, type, etc.). Decoration in this case is disabled regardless of which window I choose.

If you are sure that all _OB_APP* properties are the same, then there is no way for the window manager (openbox) to apply different settings for each window.

Closing this issue.  Please re-open if needed.


Kusto Queries for ER Bandwidth Utilization not returning any results

Hi,
I am running the provided Kusto Queries for ER Bandwidth Utilization and they are not returning any results. It appears that the SubType "ExpressRouteCircuitUtilization" does not exist anymore? I do have NPM configured and diagnostics shipping log information into Log Analytics.
What query should I run in order to get this info.
Thanks,
George

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

ID: cfb056c1-50bf-ac78-9332-4fd8de94620a
Version Independent ID: 344d259f-3779-9d03-b109-d76b1d0197fb
Content: FAQs - Network Performance Monitor solution in Azure
Content Source: articles/azure-monitor/insights/network-performance-monitor-faq.md
Service: azure-monitor
Sub-service: logs
GitHub Login: @vinynigam
Microsoft Alias: vinigam

Thanks for your comment. We are actively investigating and will get back to you shortly. Thanks for your patience.

Hi ,
Please use ERCircuitTotalUtilization
Updating docs right away.
Viny

On 06-Nov-2019, at 10:43 PM, wreckergibb<EMAIL_ADDRESS>wrote:
ExpressRouteCircuitUtilization

Doc is now updated. Please check and close the issue.

thanks for the update @vinynigam.
we are now closing this isssue.


Graph editor: Labels in graph not updated after edge annotation

Is your feature request related to a problem? Please describe.
~I need Hexatomic to let me annotate existing edges in the graph editor.~
Describe the solution you'd like
~This should work the same way as annotating nodes.~
~1. If the edge has an identifier (must be displayed, at least in a tooltip if we don't want to clutter the UI), use that, e.g., a x:y #e1.~
~2. If it doesn't have an identifier, identify it via the nodes it connects, e.g., a x:y #n1 > #t1.~
This all works fine (and indeed in both syntaxes, a x:y #n1 > #t1 and a #n1 > #t1 x:y), but the edge labels aren't updated. You can only see them when deselecting and reselecting the segment!

Describe alternatives you've considered
n/a

This bug also holds for the creation of new edges with e, where the edge is seen instantly, but the annotation only after reselection of the segment.

It seems that the labels don't have a container set when the update event is fired. Without a container, the graph view does not know if the update actually belongs to the correct graphs and bails out.

Fixed in #150 by updating to a fixed Salt version. This was a bug in the notification system of Salt. For relations,the wrong listener list was used and no event was fired.


View should have a IgnoreHasFocusPropertyOnRedraw property to prevent unnecessary derived class.

Is your feature request related to a problem? Please describe.
If a view with subviews is added the clear method isn't executed and only the subviews are redrawn.
Describe the solution you'd like
Allowing the view been clear by the base class and also ignore the HasFocus property in the Redraw method. If not ignore (default) the normal color is used if the view doesn't have the focus and the focus color is used if it have the focus. If ignore, then only the normal color is used whether is focused or not.
Describe alternatives you've considered
Only by deriving from View class and overridden the Redraw method but not needed with the solution above.
Additional context
For all this work some more improvements are needed, like on CanFocus, Add, PositionCursor, Redraw, Enabled.
Code to test the issue:
			Application.Init ();
			var root1 = new View () {
				Width = 20,
				Height = 10,
				ColorScheme = Colors.Base,
				//IgnoreHasFocusPropertyOnRedraw = true,
				Enabled = false
			};
			var label1 = new Label (new string ('c', 100)) {
				Width = Dim.Fill ()
			};
			var tv1 = new TextView () {
				Y = 2,
				Height = 1,
				Text = new string ('t', 100),
				Width = Dim.Fill (),
				Multiline = false
			};
			var labelFocus1 = new Label (new string ('f', 100)) {
				Y = 4,
				Width = Dim.Fill (),
				CanFocus = true
			};

			root1.Add (label1, tv1, labelFocus1);

			var root2 = new View () {
				X = 3,
				Y = 12,
				Width = 20,
				Height = 10,
				ColorScheme = Colors.Base,
				//IgnoreHasFocusPropertyOnRedraw = true
			};
			var label2 = new Label (new string ('c', 100)) {
				Width = Dim.Fill ()
			};
			var tv2 = new TextView () {
				Y = 2,
				Height = 1,
				Text = new string ('t', 100),
				Width = Dim.Fill (),
				Multiline = false
			};
			var labelFocus2 = new Label (new string ('f', 100)) {
				Y = 4,
				Width = Dim.Fill (),
				CanFocus = true
			};

			root2.Add (label2, tv2, labelFocus2);

			var sb = new StatusBar (new StatusItem [] {
				new StatusItem(Key.F9,"~F9~ Toggle Enable", () => {
					root1.Enabled = !root1.Enabled;
					root2.Enabled = !root2.Enabled;
				}),
				//new StatusItem(Key.F10,"~F10~ Toggle IgnoreHasFocusPropertyOnRedraw", () => {
				//	root1.IgnoreHasFocusPropertyOnRedraw = !root1.IgnoreHasFocusPropertyOnRedraw;
				//	root2.IgnoreHasFocusPropertyOnRedraw = !root2.IgnoreHasFocusPropertyOnRedraw;
				//	root1.SetNeedsDisplay();
				//	root2.SetNeedsDisplay();
				//})
			});

			Application.Top.Add (root1, root2, sb);
			Application.Run (Application.Top);

Try this code above and the output is this:

After the fix, please remove all the commented code and the output is this:

I vote we put the goal of this issue in as a requirement for v2 and not worry a trying to fix it in v1.
I have been working hard on refactoring View for v2 and, by-default, a lot of redraw issues (border, focus, title, text, clear, clip, ...) become a lot cleaner.
The key is making Bounds actually be sensible. It is such a horrifically absurd model in v1 and the root of much of the complexity that leads us to solutions like this PR.
My design will most likely be a significant breaking change for apps, but I have ideas on how to mitigate most of that.

I vote we put the goal of this issue in as a requirement for v2 and not worry a trying to fix it in v1.

Well the PR has improvements that will benefit also in the v1.

I have been working hard on refactoring View for v2 and, by-default, a lot of redraw issues (border, focus, title, text, clear, clip, ...) become a lot cleaner.

But it there is some changes you can leverage is better. Also I have another fixes on another PR's that you may take a look when you have time.

The key is making Bounds actually be sensible. It is such a horrifically absurd model in v1 and the root of much of the complexity that leads us to solutions like this PR.

Bounds as I know always represented the view relative coord with a Point.Empty and with some size. The Frame represent the screen relative with a non empty Point and size.

My design will most likely be a significant breaking change for apps, but I have ideas on how to mitigate most of that.

Good. Take only the good changes and ignore the bad ones.


Add missing help text for some CMS options

I read the code for apps/cms.c, and traced through the underlying CMS_xxx API calls.
Unfortunately many of those functions are not documented.
I tried to make educated guesses as to what is going on.
This could be backported.

Added "Fixes: #9952" to the commit.

Updated commit pushed based on information from the cms.pod page.

Thanks @beldmit, updated commit pushed to address your feedback.

Merged. Many thanks!

thanks for the helpful reviews!


SOLR-16462: Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)

https://issues.apache.org/jira/browse/SOLR-16462

Description
This pull request implements V2 equivalent endpoints for the Snapshot API (Create, List, and Delete).
Solution
I created a SnapshotAPI class that houses new v2 implementations of the CreateSnapshot, ListSnapshot, and DeleteSnapshot operations. The SnapshotAPI endpoints were implemented using the Jersey JAX-RS reference implementation. The original CoreAdminOperation implementations were modified to call the new SnapshotAPI methods. The backup/restore reference documentation has been updated to show both V1 and V2 Snapshot API examples.
Tests
No new tests were added, but I would be willing to add some if needed. There are existing tests that check that both the coreName and commitName were passed into a given Snapshot operation. Since those values are now part of the URL, I didn't see any reason to test for that against the new V2 methods.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[ ] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.
[x] I have added tests for my changes.
[x] I have added documentation for the Reference Guide

I believe I've covered most of your first round of comments @gerlowskija , aside from tests and the uses of the squash method on the ListSnapshotAPI. I also responded to your thoughts on the async handling code back on the jira ticket as well. I'll work to add some tests focused on this new CoreSnapshotAPI class while we work through the our async game plan.

Awesome; thanks John.  I replied on JIRA, about the async stuff as well, so I think that's everything.  Lmk if I missed a question though!
Feel free to push up whatever you've got from time to time if you're interested in a sanity check on the  "delta", even if it's not quite "finished" yet.

Recent changes (@Schema documentation, failure-case unit tests, API class renaming) all look great.
To summarize where we are, I think there's two remaining items to clear up before this can be merged:

A decision on whether we should hold strict backcompat for the v1 LISTSNAPSHOT response format, or go with the (clearly preferable) syntax the v2 API has currently.  I opened a dev@ thread about that, which slows this PR down a bit, but it's better to get consensus on this rather than risk someone complaining later.  If there's no objections by mid-next week I say we go forward with the improved syntax.
Handling of the async param.  I think I offered to help with this in JIRA; so I'll take a crack at it if you haven't already started in on it @Jdurham2843 ?

Awesome, sounds good! The new syntax definitely looks better (and may be easier to parse if someone were using the API from another program), but it's probably a good idea to get consensus first.
If we're still waiting on item 1, I'll go ahead and take a stab at it. Also, in reference to the your jira response, I'd be interested in working together on a more general solution too. It sounds like a good way to get familiar with other APIs in Solr.
I added three tests just checking the errors response from CoreSnapshotAPI. I started to write some tests (heavily mocked) to verify the response output, but ran into an issue where I couldn't mock the IndexDeletionPolicyWrapper since its a final class. Are there any additional things you can think of that would be worth testing? My current thinking is that we're just trying to test/validate the interface (request, response, errors).

(pending)
I created a new CoreAdminAPIBase class to house the async handling code. The class takes the async code from CoreAdminHandler and wraps it in handle method. The handle method then takes it some parameters from each endpoint along with a Supplier. This appears to work the same as the original V1 APIs async code. However, injecting a SolrQueryRequest and SolrQueryResponse has led to a MultiException stack error. See below for the output.
I figured out a way to write the response validation tests without needing to mock. It turns out everything I needed was already in the Test's base class. I just had to call a few methods to setup the TestHarness.

Let me know what you think!
MultiException error when calling new V2 methods:
Nov 06, 2022 7:01:24 PM org.glassfish.jersey.internal.Errors logErrors
WARNING: The following warnings have been detected: WARNING: HK2 failure has been detected in a code that does not run in an active Jers
ey Error scope.
WARNING: Unknown HK2 failure detected:
MultiException stack 1 of 3
java.lang.NullPointerException
        at org.glassfish.jersey.server.internal.process.RequestProcessingConfigurator$ContainerRequestFactory.get(RequestProcessingConfi
gurator.java:67)
        at org.glassfish.jersey.server.internal.process.RequestProcessingConfigurator$ContainerRequestFactory.get(RequestProcessingConfi
gurator.java:56)
        at org.glassfish.jersey.inject.hk2.SupplierFactoryBridge.provide(SupplierFactoryBridge.java:76)
        at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:129)
        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:463)
        at org.glassfish.jersey.inject.hk2.RequestContext.findOrCreate(RequestContext.java:59)
        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2102)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
        at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:679)
        at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:54)
        at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:188)
        at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:205)
        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:334)
        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:463)
        at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:46)
        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2102)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:67)
        at org.jvnet.hk2.internal.FactoryCreator.dispose(FactoryCreator.java:151)
        at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:518)
        at org.glassfish.jersey.inject.hk2.RequestContext.lambda$findOrCreate$0(RequestContext.java:60)
        at org.glassfish.jersey.internal.inject.ForeignDescriptorImpl.dispose(ForeignDescriptorImpl.java:63)
        at org.glassfish.jersey.inject.hk2.Hk2RequestScope$Instance.remove(Hk2RequestScope.java:126)
        at java.base/java.lang.Iterable.forEach(Iterable.java:75)
        at org.glassfish.jersey.inject.hk2.Hk2RequestScope$Instance.release(Hk2RequestScope.java:143)
        at org.glassfish.jersey.process.internal.RequestScope.release(RequestScope.java:246)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:267)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684)
        at org.apache.solr.api.V2HttpCall.invokeJerseyRequest(V2HttpCall.java:371)
        at org.apache.solr.api.V2HttpCall.invokeJerseyRequest(V2HttpCall.java:338)
        at org.apache.solr.api.V2HttpCall.executeCoreRequest(V2HttpCall.java:452)
        at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:554)
        at org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
        at org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:219)
        at org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
        at org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
        at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201)
        at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
        at org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
        at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:772)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.Server.handle(Server.java:516)
        at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
        at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
        at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
        at java.base/java.lang.Thread.run(Thread.java:829)
MultiException stack 2 of 3
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of org.apache.solr.jersey.InjectionFactories$SolrQueryR
equestFactory errors were found
        at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:224)
        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:334)
        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:463)
        at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:46)
        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2102)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:67)
        at org.jvnet.hk2.internal.FactoryCreator.dispose(FactoryCreator.java:151)
        at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:518)
        at org.glassfish.jersey.inject.hk2.RequestContext.lambda$findOrCreate$0(RequestContext.java:60)
        at org.glassfish.jersey.internal.inject.ForeignDescriptorImpl.dispose(ForeignDescriptorImpl.java:63)
        at org.glassfish.jersey.inject.hk2.Hk2RequestScope$Instance.remove(Hk2RequestScope.java:126)
        at java.base/java.lang.Iterable.forEach(Iterable.java:75)
        at org.glassfish.jersey.inject.hk2.Hk2RequestScope$Instance.release(Hk2RequestScope.java:143)
        at org.glassfish.jersey.process.internal.RequestScope.release(RequestScope.java:246)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:267)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684)
        at org.apache.solr.api.V2HttpCall.invokeJerseyRequest(V2HttpCall.java:371)
        at org.apache.solr.api.V2HttpCall.invokeJerseyRequest(V2HttpCall.java:338)
        at org.apache.solr.api.V2HttpCall.executeCoreRequest(V2HttpCall.java:452)
        at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:554)
        at org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
        at org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:219)
        at org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
        at org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
        at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201)
        at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
        at org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
        at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:772)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.Server.handle(Server.java:516)
        at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
        at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
        at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
        at java.base/java.lang.Thread.run(Thread.java:829)
MultiException stack 3 of 3
java.lang.IllegalStateException: Unable to perform operation: resolve on org.apache.solr.jersey.InjectionFactories$SolrQueryRequestFacto
ry
        at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:363)
        at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:463)
        at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:46)
        at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2102)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
        at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:67)
        at org.jvnet.hk2.internal.FactoryCreator.dispose(FactoryCreator.java:151)
        at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:518)
        at org.glassfish.jersey.inject.hk2.RequestContext.lambda$findOrCreate$0(RequestContext.java:60)
        at org.glassfish.jersey.internal.inject.ForeignDescriptorImpl.dispose(ForeignDescriptorImpl.java:63)
        at org.glassfish.jersey.inject.hk2.Hk2RequestScope$Instance.remove(Hk2RequestScope.java:126)
        at java.base/java.lang.Iterable.forEach(Iterable.java:75)
        at org.glassfish.jersey.inject.hk2.Hk2RequestScope$Instance.release(Hk2RequestScope.java:143)
        at org.glassfish.jersey.process.internal.RequestScope.release(RequestScope.java:246)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:267)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:234)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684)
        at org.apache.solr.api.V2HttpCall.invokeJerseyRequest(V2HttpCall.java:371)
        at org.apache.solr.api.V2HttpCall.invokeJerseyRequest(V2HttpCall.java:338)
        at org.apache.solr.api.V2HttpCall.executeCoreRequest(V2HttpCall.java:452)
        at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:554)
        at org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251)
        at org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:219)
        at org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:257)
        at org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:227)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
        at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201)
        at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
        at org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
        at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:772)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.Server.handle(Server.java:516)
        at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
        at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
        at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
        at java.base/java.lang.Thread.run(Thread.java:829)

If we're still waiting on item 1, I'll go ahead and take a stab at the async code.

Alright, thanks for grabbing that!  On item (1), I think the conclusion on that dev@ thread was that we're good to change the appearance here, since this very much looks like a bug.
I'll take a look sometime today to review what you've added.

Update:

I added some JavaDocs to CoreAdminAPIBase and CoreSnapshotAPI. I tried to follow the same general patterns I saw in JerseyResource and in the SchemaNameAPI class.
I made an attempt at reusing the executor and statusMap from CoreAdminHandler in the CoreAdminAPIBase class. Instead of Injecting both separately, I moved them both into a static nested class on CoreAdminHandler and wrote some code to Inject that. Even if we decide not to use this version and instead you have a better approach, we can revert these changes. I at least wanted to give it a shot first!
I added the V2 squash static method to the V1 ListSnapshots operation.

Hi @Jdurham2843
Just wanted to give you a short update on my lack of progress on this.
It is definitely still on my radar, but I've been a little distracted recently focusing on a performance regression that someone noticed in the JAX-RS framework overall: another committer noticed that the recent addition of the JAX-RS framework has slowed down Solr startup, in some cases quite significantly.  That's turned into a big blocker for the JAX-RS work overall: there's even talk of deferring the release of our JAX-RS v2 APIs until that perf regression can be mitigated.
So most of my focus has shifted to that - after all, it's not much good focusing on individual JAX-RS APIs if shipping the whole framework gets delayed 😛 If you're curious, see SOLR-16531 for more details on all this.
Anyway, that's all to say that I haven't gotten to this PR, but that I haven't forgotten it or let it fall off my radar.  I'm just focusing on this performance blocker, and plan to return to this when that's finished.  I appreciate all your work here and definitely haven't forgotten it!

That doesn't sound like any fun, but I totally get it and no worries! This work should be here whenever your in a position to look at it. Hopefully the regression isn't too hard to remediate.

Re-reading the conversation here, it sounds like you had addressed all of the sticking points (particularly the executor injection and async handling), and it's ready for a re-review?  Lmk if I've overlooked some detail, but otherwise I'll try to take a look in the next workday or two!

Yep, I think it should be ready for review! I made an attempt to handle async requests, but if you decide there's a better way to do it, I can look at reverting those changes. I also went ahead and did a rebase to bring the branch up to date with main as well.

Hey! I'll start testing the changes you made, and see if the injection errors are still around. From a first look at the changes, I agree with all of them. Regarding the near-duplicate async processing code: I remember trying to dedupe it, but hit a point where I couldn't see how to do it without creating a mess. I'm glad you found a way to make it work, because it felt kind of wrong to leave that in the codebase.

I did some testing and things appeared to be working correctly. I am still seeing the injection exception. Any thoughts what that might be?

Hmm, I haven't noticed that Injection error in the logs, though maybe I missed it since the API returns successfully?
I'll play around with it some more and pay more attention to the logs on successful API calls. 🤔

From what I can tell, the injection exception isn't making it into any logs. Instead its being spat out into the terminal where I ran the solr start command. I'm only seeing this error when running in Windows (Powershell or Command Prompt). If I run it under Ubuntu (wsl2), I don't see the error at all. Maybe something OS specific?

I'm only seeing this error when running in Windows

Huh, that's a weird wrinkle.  There's nothing OS-specific (that I'm aware of) in any of the dependency-injection stuff.  And, fwiw, I took another stab at reproducing on MacOS this morning and couldn't see any of the logs either.
If I had to guess, I'd say that this is probably related to how Solr uses separate Jersey applications for "container" and "per-core" APIs.  There are some situations where Solr isn't sure what "type" an incoming request is, so it tries sending the request to one Jersey app, and only tries the second if the first errors out.  That'd help explain how we see clear errors in the logs despite the request ultimately succeeding: one Jersey app fails with the observed errors before the second Jersey app succeeds.
But I'm stumped why this behavior would be OS dependent, or even why it'd fail with an injection error.  In the scenario above the first Jersey app typically fails with a NotFoundException that is handled specially so that it doesn't pollute the logs.

In terms of moving forward here, if the requests failed on Windows it'd be a very different matter.  But I think the extra noise in the logs is probably tolerable for now given that v2 is an experimental feature.  Absolutely something that needs fixed, but it feels like a framework problem and not something inherent to this PR.
I'll plan on merging this to 'main' and letting it bake a bit before backporting.

Sounds good, thanks for working with me on this!


Console.info statements in webpack config file causes resolve error

Environment:

linter-ui-default 1.7.1
Atom 1.37
webpack 4
Mac 10.13.6

Example webpack config file:
const webpack = require('webpack');
const path = require('path');

module.exports = () => {
    const configToUse = {
        cache: true,
    };

    // eslint-disable-next-line
    console.info('This is breaking linter-ui-default.');
    return configToUse;
};

Result:
All import statements in a repository's files are flagged as "Unable to resolve path to module". Below is a screenshot of the resolve errors from Atom's bottom dock.

What happens on the command line?

Command line is clean with no linter errors.

In that case, that suggests that Atom isn't using node, which would be strange. You may need to file a bug on Atom (since the command line is the source of truth)

Huh, ok... @Arcanemagus curious if you have thoughts on this?
I'm just trying to get the ticket to the right place and don't want to spam repos.

As I already told you in the other issue this is either a configuration problem or a bug, but without a way to reproduce this it's impossible to say for sure.

@Arcanemagus I was referring to specifically filing an issue in Atom as @ljharb suggested. I thought you may have some insight to the inner workings of Atom since you build packages for it and I do not.

This extremely unlikely to be an issue with Atom itself. If it's an issue at all in that part of the ecosystem it's something in how linter-eslint is running things.

As I already told you in the other issue this is either a configuration problem or a bug, but without a way to reproduce this it's impossible to say for sure.

It certainly might not be in Atom, but it very well might be in whatever Atom plugin you're using - it's definitely not in eslint or this plugin, tho, since it works on the command line.

Ok thanks; then I'm closing this out.
Based on the comments, it sounds like an issue with linter-eslint. Until I have a public code available to demo the problem per @Arcanemagus request, I won't be opening a new issue in that repo (though if it needs to be documented, he may be able to transfer the related issue since he's a contributor to both).


Hardcoded zIndex: 1000on Modal

Issue description

version #3.9.1
components: Modal.js

In the following commit  a hardcoded zindex = 1000 was added to the root element of the modal that is created in Modal.js. This can be a problem for users that have elements above z-index 1000 since the modal itself and the backdrop will be underneath these elements. We have solved this temporarily by using the 3.9.0 release, but it would be nice if the hardcoded 1000 on line 129 in Modal.js can be made configurable or the issue can be resolved in some other way.

+1 to making it configurable

@TheSharpieOne That was quick, thanks! :)


New warning in 5.2.1

After updating from 5.2.0 to 5.2.1 we started getting a new warning:
ld: warning: ignoring file ~/project/Pods/CardIO/CardIO/libopencv_core.a, missing required architecture x86_64 in file ~/project/Pods/CardIO/CardIO/libopencv_core.a (3 slices)
ld: warning: ignoring file ~/project/Pods/CardIO/CardIO/libopencv_imgproc.a, missing required architecture x86_64 in file ~/project/Pods/CardIO/CardIO/libopencv_imgproc.a (3 slices)

It looks like the opencv static libraries weren't compiled as they should have been. You can see the difference in architectures vs the CardIO static library:
% file libopencv_core.a
libopencv_core.a: Mach-O universal binary with 3 architectures
libopencv_core.a (for architecture armv7s):     current ar archive random library
libopencv_core.a (for architecture armv7):      current ar archive random library
libopencv_core.a (for architecture arm64):      current ar archive random library
% file libCardIO.a
libCardIO.a: Mach-O universal binary with 5 architectures
libCardIO.a (for architecture armv7):   current ar archive random library
libCardIO.a (for architecture armv7s):  current ar archive random library
libCardIO.a (for architecture i386):    current ar archive random library
libCardIO.a (for architecture x86_64):  current ar archive random library
libCardIO.a (for architecture arm64):   current ar archive random library

Since the iOS simulator lacks a camera, the simulator builds (x86_64, i386) are not supposed to include the OpenCV libraries. All OpenCV calls in card.io are under an appropriate compiler flag.
Thus, the OpenCV static libraries do not need to be built for x86_64 and i386.
Sounds like the project is failing to exclude these libraries for these architectures.

Ah interesting, that makes sense. We're including CardIO through CocoaPods, so I assume anyone using CocoaPods for this would see the same issue.

I am labeling this as an enhancement only because this seems to be fairly harmless right now. For CocoaPods, http://blog.carbonfive.com/2014/01/24/cocoapods-for-device-only-ios-libraries/ seems to be a way to change the Podspec; there didn't seem to be an easier way in a quick search.

Should be fixed in release 5.2.2. The x86_64 and i386 slices were added. Even though they aren't used, removing them presented problems with Carthage support, so the short term solution is a temporary size increase in the OpenCV libraries.


docs: add workflow description for using tfmigrate

I was more thinking about a page in Antora's documentation.

deprecated by #679


CrynnObject ID generation is not thread safe

CrynnObject uses a static variable to represent and generate ids. Currently ID generation is not thread safe.

Fixed by changing the static int to std::atomic_uint64_t


Revert "Don't hard-code essential files in copy_doc_dir"

This meant we stopped copying all JS and CSS files, which was
incorrect. Possibly there's a better way to do this, but this fixes the
immediate problem that search is broken.
Here's an example build which is broken because of the change to
copy_doc_dir:
> aws s3 ls s3://rust-docs-rs/rustdoc/tokio-eventfd/0.2.0/
                           PRE i686-unknown-linux-gnu/
                           PRE implementors/
                           PRE src/
                           PRE tokio_eventfd/
                           PRE x86_64-apple-darwin/
2021-03-23 14:25:56          9 .lock
2021-03-23 14:25:56       1691 settings.html

r? @Nemo157

I expect this to fix https://github.com/rust-lang/docs.rs/issues/1328, but haven't tested it yet.

(The diff looks big, but it's a line-for-line revert of 6f4477ba8350f6154085961fc0bdcf9fe661da9a.)

I expect this to fix #1328, but haven't tested it yet.

Oh weird, it does not. Looking into that now. This does fix search being broken though.


Proposal: Specify version of Rust platform, and lock for applications

First, some use cases:

ACME, Inc. has a large Rust application hosted on Heroku using a Rust buildpack. The application is a cash-cow: It earns a lot of money, and it has a lot of users, but it's only updated rarely. Six months after the last update, a critical bug is discovered. A two-line patch is produced, and it needs to be pushed to production.
Rustalicious LLC is a boutique software consultancy specializing in Rust applications. They help maintain ACME's cash cow application. They're also working on Rust projects for 3 other clients, in varying stages of active development and maintenance.

In these examples, both ACME and Rustalicious need to control when they upgrade their Rust toolchain. ACME is trying to push an urgent fix to production, but they haven't touched the codebase in 4 Rust releases, and they don't have the time to upgrade to the lastest Rust compiler and verify that nothing is broken. They want to make a two-line fix using their old toolchain.
Rustalicious wants to use the latest and greatest Rust compiler for everything, because it's shiny. But they have multiple maintenance mode clients who depend on different versions of the Rust platform. So they potentially need to install multiple versions of Rust side-by-side, and manage them using a specialized tool.
Prior art: Bundler + buildpacks + RVM
In the Ruby world, it's possible to use Gemfile to specify the version of Ruby that should be used with an application:
`ruby '1.9.3'`

This information is read by Heroku's Ruby buildpack, and by various third-party tools like RVM that manage multiple, parallel Ruby implementations.
Proposed solution: Treat rustc and the standard libraries like any other versioned dependency
rustc and the standard library are an actual dependency for every Rust application. So it might be reasonable to specify their version numbers somewhere in Cargo.toml:
rust = "1.1.2"

This could go either in the package section, or possibily even in the dependencies section. It could potentially allow full version specifiers, and possibly even be recorded in Cargo.lock like any other dependency.
What would Cargo do with this information?
Two possibilities come to mind:

Verify that all packages can be build with the specified version of Rust, and if not, give an error message explaining the constraints. This would offer significant value to ordinary Cargo users, because they'd get comprehensible messages telling them when they needed to upgrade their compiler, instead of random error spew from one of the libraries they're using.
Store an exact version in Cargo.lock.

Third-party tools might also read this information to configure deployment servers (e.g., buildpacks), manage parallel Rust toolchains (e.g. RVM etc. for Rust), and decide which Rust version(s) should be used for continuous integration builds.
Alternatives

Trust the compiler and standard libs to never have regressions.
Store this information in a .rust_version file and coordinate between tool developers.

I'm not hugely attached to the details of this proposal, but I will need to address both the ACME and Rustalicious use cases in the future, with any luck. :-)
If it's useful, I'd be interested in contributing some code, but I'd need code review from the Cargo team.

This is largely in the same vein as #837 in that for now I don't think that we're ready to make any commitments about the version of rust you're compiling with.
https://github.com/rust-lang/rfcs/pull/507 has some information about how Cargo may apply heuristics to warn you if your version of Rust is out of date or perhaps affect package resolution to weed out those which don't work on the version of Rust installed, but these options are currently dependent on rustc support.
In general there's not a lot of action to take here right now I believe. I'd like to get some experience with stable Rust and/or our release cycle before we hasten in a system for juggling Rust versions (it may not even be necessary!)
As a result, I'm going to close this for now.


'bool' object has no attribute 'provider'

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az webapp list-runtimes
Errors:
'bool' object has no attribute 'provider'
Traceback (most recent call last):
python3.6/site-packages/knack/cli.py, ln 206, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 608, in execute
    raise ex
cli/core/commands/__init__.py, ln 666, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
cli/core/commands/__init__.py, ln 659, in _run_job
    six.reraise(*sys.exc_info())
...
cli/command_modules/appservice/custom.py, ln 704, in list_runtimes
    return [s['displayName'] for s in runtime_helper.stacks]
cli/command_modules/appservice/custom.py, ln 2159, in stacks
    self._load_stacks()
cli/command_modules/appservice/custom.py, ln 2180, in _load_stacks
    raw_stacks = self._client.provider.get_available_stacks(os_type_selected=os_type, raw=True)
AttributeError: 'bool' object has no attribute 'provider'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az webapp list-runtimes --linux

Expected Behavior
Environment Summary
Linux-4.15.0-1067-azure-x86_64-with-debian-stretch-sid
Python 3.6.5
Shell: bash

azure-cli 2.0.81

Additional Context

@patriziotomato , thanks for reporting, we are looking at this ?

Same issue here. Just updated to az 2.0.81.
The command failed with an unexpected error. Here is the traceback:

'bool' object has no attribute 'provider'
Traceback (most recent call last):
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\knack\knack\cli.py", line 206, in invoke   File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli-core\azure\cli\core\commands\__init__.py", line 608, in execute
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli-core\azure\cli\core\commands\__init__.py", line 666, in _run_jobs_serially
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli-core\azure\cli\core\commands\__init__.py", line 659, in _run_job
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\six\six.py", line 703, in reraise          File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli-core\azure\cli\core\commands\__init__.py", line 636, in _run_job
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli-core\azure\cli\core\commands\__init__.py", line 306, in __call__
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli-core\azure\cli\core\__init__.py", line 493, in default_command_handler
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli\azure\cli\command_modules\appservice\custom.py", line 704, in list_runtimes
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli\azure\cli\command_modules\appservice\custom.py", line 2159, in stacks
  File "C:\Users\VSSADM~1\AppData\Local\Temp\pip-install-1o1fsnhi\azure-cli\azure\cli\command_modules\appservice\custom.py", line 2180, in _load_stacks
AttributeError: 'bool' object has no attribute 'provider'

I can confirm that the issue does not exist when you run from Cloud shell through the Azure portal.
But it does show up when you run the command on a local machine.

Confirming as well. RHEL7 just updated to 2.0.81
az webapp list-runtimes

The command failed with an unexpected error. Here is the traceback:

'bool' object has no attribute 'provider'
Traceback (most recent call last):
  File "/usr/lib64/az/lib/python3.6/site-packages/knack/cli.py", line 206, in invoke
    cmd_result = self.invocation.execute(args)
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 608, in execute
    raise ex
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 666, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 659, in _run_job
    six.reraise(*sys.exc_info())
  File "/usr/lib64/az/lib/python3.6/site-packages/six.py", line 693, in reraise
    raise value
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 636, in _run_job
    result = cmd_copy(params)
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 306, in __call__
    return self.handler(*args, **kwargs)
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/core/__init__.py", line 493, in default_command_handler
    return op(**command_args)
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/command_modules/appservice/custom.py", line 704, in list_runtimes
    return [s['displayName'] for s in runtime_helper.stacks]
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/command_modules/appservice/custom.py", line 2159, in stacks
    self._load_stacks()
  File "/usr/lib64/az/lib/python3.6/site-packages/azure/cli/command_modules/appservice/custom.py", line 2180, in _load_stacks
    raw_stacks = self._client.provider.get_available_stacks(os_type_selected=os_type, raw=True)
AttributeError: 'bool' object has no attribute 'provider'

To open an issue, please run: 'az feedback'

az --version
azure-cli                         2.0.81 *

command-modules-nspkg              2.0.3
core                              2.0.81 *
nspkg                              3.0.4
telemetry                          1.0.4

Extensions:
log-analytics                      0.1.4

we had a regression with 2.0.81 - we have since fixed up the list-runtimes command - if you can try it with latest version please let us know. Thanks!


Log to syslog

I like syslog, so I'd like to ask for support for it.
glauth is able to log to syslog, too.

Good point. Certainly for the next release  via a logrus hooks


Delete project role

Codecov Report

Merging #446 (96a0be2) into develop (29d4ee9) will increase coverage by 0.56563%.
The diff coverage is 100.00000%.

@@                 Coverage Diff                 @@
##             develop        #446         +/-   ##
===================================================
+ Coverage   95.85594%   96.42157%   +0.56562%
===================================================
  Files             82          82
  Lines           2027        2040         +13
===================================================
+ Hits            1943        1967         +24
+ Misses            84          73         -11

Impacted Files
Coverage Δ

backend/src/app/logic/projects.py
82.50000% <100.00000%> (+6.18420%)
:arrow_up:

...kend/src/app/routers/editions/projects/projects.py
97.72727% <100.00000%> (+5.04434%)
:arrow_up:

backend/src/database/crud/projects.py
89.39394% <100.00000%> (+11.97459%)
:arrow_up:

backend/src/app/logic/students.py
98.03922% <0.00000%> (ø)

backend/src/app/schemas/students.py
100.00000% <0.00000%> (ø)

backend/src/database/crud/students.py
100.00000% <0.00000%> (ø)

...kend/src/app/routers/editions/students/students.py
100.00000% <0.00000%> (ø)


Adding updated metrics + formatting

Changes

Updating the single_file_postprocessing to accept multiple threshold probability values, as per request from Dierdre.
Updating the constants to allow for aggregation across all of the default thresholds
Updating country_lvl_aggregate to calculate the number of ius that reach a threshold for all the given "threshold metrics".

Testing
Ran it on local oncho data to verify the output is as expected.
Updated tests to account for parameter changes, and validated that the test suite passed.

I think I'm a bit confused by the country level aggregation, and the test didn't really clarify it for me tbh - perhaps we can have a chat tomorrow to work through this.

Clarified on a call, that for countries we now have
Percentage of IUs that reached threshold in X percent of runs.
Number of IUs that reached threshold in X percent of runs.
I will double check these aren't showing up in LF and then send you files if not.


add encoding to UTF-8 for res.json and res.jsonp

Based on the IETF RFC4627:

JSON text SHALL be encoded in Unicode.  The default encoding is UTF-8

I updated some references for the res.json and res.jsonp. The thing is that the tests are passing w/o additional changes so I am wondering if I am missing something here.

Pretty sure this is something we would need to land in v5 right? I think explicit is sometimes better, but I would need to do some research on how different clients behave to know for sure. Have you looked beyond the spec to see if there is some reason this might have been left off despite being pretty clearly specified?

It was left off bc code elsewhere adds it already. If you look at the http response qithout this change the charset is there in published versions.
The reason it is added elsewhere is bc nothing in that function is writing out utf-8 bytes to the response, so it leaves the part of the code that does that responsible to setting rhe charset of the bytes it actually wrote on the wire.

Ah, that makes sense. Thanks for the clarification! Do you have a link to where it does happen, just making sure I understand this going forward.

Oh yeah, this already happens in other parts of the code
https://github.com/expressjs/express/blob/e4a61bd88e2f170eab64d937f3bf6c0812b4a649/lib/response.js#L144-L153


Azure Functions

State:
MacOS
Dotnet 2.2.101 is installed and this is working from the terminal: dotnet --version
C# extension is installed
Repro steps:
<Enter steps to reproduce issue>

Open VSCode
Open Azure Functions extensions
Click create new project icon
Select c#
Error occurs

Note:
Using right-click Create function app in Azure... is working as expected
Action: azureFunctions.createNewProject
Error type: Error
Error Message: You must have the .NET CLI installed to perform this operation.
Version: 0.13.0
OS: darwin

When you say "this is working from the terminal" are you talking about your system terminal or the terminal from within VS Code? Can you try from the terminal within VS Code? I'm wondering if dotnet isn't in your PATH in VS Code for some reason...


Missing whitespace in Helm url field

Oh good catch, thanks. I think this error was introduced as part of an early bug in our code-generator, and has not been regenerated since then. When we do our next release, this should be fixed.

/ok-to-test

/lgtm


Update Mocha to 4.0.1

Avoid breaking bitkeeper test

Argh, failed. Needs mantoni/mochify.js#160 to be merged, as well as updating mochify after that.


Cannot find a way to send data via segue from Main to Table

New Issue Checklist

I have read the guidelines for contributing and I understand:

[ x] My issue is happening in the latest version of SideMenu.
[ x] My issue was not solved in the README.
[x ] My issue can not be answered on stackoverflow.com.
[ x] My issue is not a request for new functionality that I am unwilling to build and contribute with a pull request.
[x ] My issue is reproducible in the demo project.

Issue Description

Hi, I didn't find a way to send data via segue to the TableViewController since is the 3rd view and the MainViewController goes to SideMenuNavigationController.

@sebastianvirlan your request is vague, but there's nothing special needed to "send data" between view controllers. It's the same you process you would do if you were not using SideMenu. Data is most commonly passed between view controllers using delegates or notifications. You must take your problem to stackoverflow.com for help.

The issue is that there doesn't appear to be any way to do prepareForSegue() to set up the view controllers that are being presented.   For example, the menu would be very useful if prepareForSegue() was called within the side menu view controller before returning back to the main view controller, so we could modify an object within the main view controller based on what selection the user just made.

This is an easily solved problem. From any of your view controllers, override viewWillAppear to set  or get the appropriate data you want based on the presentingViewController or presentedViewController. If you need more help please go to stackoverflow.

@sebastianvirlan @tjvanpat Any solution found to this issue?

Yes, the answer is to use observers and notifications just like he says.   The context for this code isn't important, just pay attention to the addObserver() calls.
    private func setupSideMenu() {
        // Define the menu
        if let smnc = storyboard?.instantiateViewController(withIdentifier: Constants.sbidSideMenuLeftMapOptions) as? UISideMenuNavigationController {
            SideMenuManager.default.menuLeftNavigationController = smnc

            // Enable gestures
            guard (self.navigationController != nil) else {
                log.error("self.navigationController is nil.")
                return
            }
            SideMenuManager.default.menuAddScreenEdgePanGesturesToPresent(toView: self.navigationController!.view)
        } else {
            assertionFailure("Unable to get SideMenu navigation controller: '\(type(of: storyboard?.instantiateViewController(withIdentifier: Constants.sbidSideMenuLeftMapOptions)))'")
        }
    }

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        setupSideMenu()

        NotificationCenter.default.addObserver(self,
                                               selector: #selector(self.handleMapTypeSelected(_:)),
                                               name: NSNotification.Name(Constants.notificationMapOptionsSetMapType),
                                               object: nil)
        NotificationCenter.default.addObserver(self,
                                               selector: #selector(self.handleRemoveAllLocations(_:)),
                                               name: NSNotification.Name(Constants.notificationMapOptionsRemoveLocations),
                                               object: nil)
    }

And then in the SideMenu TableViewController you post() the notification:
                    DispatchQueue.main.async {
                        NotificationCenter.default.post(name: NSNotification.Name(Constants.notificationMapOptionsSetMapType),
                                                        object: nil,
                                                        userInfo: [Constants.notificationDictMapOptionsMapType : MKMapType.standard])
                    }


QUARKUS-177 DOC: Using simplified Hibernate ORM with Panache

This is a test of single-sourcing. Other details in QUARKUS-177.
Community doc
Enterprise doc

@FroMage I see I missed a few of your updates. I think I have addressed all now. I closed the ones I was able to verify, but left open any that I had a question about. Would you please confirm and let me know if I can move this to QE review, or if you want further updates?

@maxandersen if you could help us understand why I can't resolve conversation on the review comments I make, I think it would help tremendously keeping track of the feedback. Also why can't @emmurphy1 comment on those and needs to edit my comments? We're both suffering from a massive usability issue in this review.

i cant explain why emurphy cant comment
To your comments since i can and i have less permjssions.
Why you cant resolve probably has to do with this pr being open in emurphys personal branch rather than quarkusio where you habe commit access and thus allowed to resolve comments on others PR.

Aha, ok, in that case @emmurphy1 should probably grant us commit access?


MSID: 88275 Version: 1 DOI: 2<IP_ADDRESS>7849

"msas": "Stem Cells and Regenerative Medicine"
"msid": "88275"
"preprintDoi": "10.1101/2<IP_ADDRESS>7849"
"Reviewed Preprint posted": "2023-07-03"
"Sent for peer review": "2023-04-21"
"Posted to bioRxiv": "2023-04-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>7849v1")
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v1/by-publisher/elife/get-by-manuscript-id?manuscript_id=88275)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/88275/v1)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: https://github.com/elifesciences/enhanced-preprints-data/pull/115
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews
Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>7849)
[x] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[x] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/88275/v1/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/88275)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/88275

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/88275

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/88275/v1/88275-v1.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/88275)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

Corresponding author information needs fixing

Fix in https://github.com/elifesciences/enhanced-preprints-biorxiv-xslt/pull/54


How do I get it to do side-by-side?

I followed the instructions from the README:
npm install -g git-split-diffs

git config --global core.pager "git-split-diffs --color | less -RFX"

But I don't see side-by-side diffs.
git version:
git version 2.31.1
os version:
Darwin 19.6.0 Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64 x86_64

The default behavior is that on narrow windows, we revert back to unified diffs because split diffs are hard to read if your window is too narrow: https://github.com/banga/git-split-diffs#narrow-terminals. If you want, you can disable this:
git config split-diffs.min-line-width 0

Thanks a lot!


Support Zeebe's user task forms

Since Zeebe 1.0.0, user tasks and task forms are supported: https://docs.camunda.io/docs/reference/bpmn-processes/user-tasks/user-tasks#user-task-forms
The task forms are a new part of the Camunda stack and can be modeled directly in the modeler: https://docs.camunda.io/docs/product-manuals/tasklist/userguide/camunda-forms
Replace the previous task forms and form fields with the official Camunda forms. The form viewer can be integrated as described here: https://github.com/bpmn-io/form-js/tree/master/packages/form-js-viewer

@saig0 Hi, will you please guide me, where to get "userTaskForm"? Now I can get "userTaskForm_id" from "customHeaders" by "io.camunda.zeebe:formKey".
But where to get "userTaskForm" content json string by "userTaskForm_id"?
Do I need to add "addProcessListener“  to get the all "process" xml content? Because  the userTaskFrom content lay on:
<process ... >  ...
xml node.

"But it order to read the form, we need to import the process record. The form is stored in the process extension zeebe:userTaskForm."
I will check this path, thx.
@saig0

Custom form logic can be associated with the userTaskForm_id, and the corresponding permissions can be verified, but can not be stored in the userTaskForm

A similar feature was implemented in the Zeebe-Play project. A contributor could adopt the relevant changes from the following PRs:

https://github.com/camunda-community-hub/zeebe-play/pull/61
https://github.com/camunda-community-hub/zeebe-play/pull/69
https://github.com/camunda-community-hub/zeebe-play/pull/81


RNA-Seq enhancement - User request

It would be nice if we could get a fastqc report and the ability to trim
reads on uploaded fastq files.

fastqc is now run on each of the read files as part of the RNA-seq pipeline.
We now also have readqc service that allow users to run fastqc and trim reads.
Closing the ticket.


Wrong syntax highlighting for function signature

(function) def foo(callback: ((_T@foo) -> bool) | None = None) -> (_T@foo | None)
#                                ^                ^^^^ ^ ^^^^        ^      ^^^^

Plus, I would like to see foos in _T@foo have a special scope but that's less important.

I'm assuming that something like ((_T@foo) -> bool) is not a valid syntax in this context (or anywhere)? Which makes me wonder why try to handle a syntax that is clearly not valid Python syntax. It is bound to fail since there are no rules and regulations on what the server can use.
But if you have the strength and will to fight against this then feel free.

I'm assuming that something like ((_T@foo) -> bool) is not a valid syntax in this context (or even anywhere)? Which makes me wonder why do we try to handle a syntax that is clearly not valid Python syntax. It is bound to fail since there are no rules and regulations on what the server can use.

Is this the point that we have this file? https://github.com/sublimelsp/LSP-pyright/blob/acf63fe3f1879521eef4a99dd01ad95c456bdf57/syntaxes/pyright.sublime-syntax
Otherwise, we just use exact Python syntax for the signature popup and for any weird highlighting we just say it's not Python.

yeah but initially my understanding was that it is only the prefix that we have to get rid of and the rest will be a valid python syntax which would be trivial to handle. Now it's turning into a completely different language :)


Spaces in job name cause exception

Looks like an exception handling URIs. The job name in this case is ATS Testing
Caused by: java.lang.IllegalArgumentException: Illegal character in path at index 0: "jobs/ATS%20Testing/config.xml"
Mar 09, 2016 6:33:23 PM FINE hudson.plugins.scm_sync_configuration.SCMManipulator
Checking in SCM files ...
Mar 09, 2016 6:33:23 PM FINER org.apache.maven.scm.manager.ScmManager checkIn
THROW
org.apache.maven.scm.ScmException: Exception while executing SCM command.
	at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:63)
	at org.apache.maven.scm.provider.git.AbstractGitScmProvider.executeCommand(AbstractGitScmProvider.java:291)
	at org.apache.maven.scm.provider.git.AbstractGitScmProvider.checkin(AbstractGitScmProvider.java:217)
	at org.apache.maven.scm.provider.AbstractScmProvider.checkIn(AbstractScmProvider.java:415)
	at org.apache.maven.scm.provider.AbstractScmProvider.checkIn(AbstractScmProvider.java:397)
	at org.apache.maven.scm.manager.AbstractScmManager.checkIn(AbstractScmManager.java:423)
	at hudson.plugins.scm_sync_configuration.SCMManipulator.checkinFiles(SCMManipulator.java:241)
	at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness.processCommitsQueue(ScmSyncConfigurationBusiness.java:223)
	at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness.access$000(ScmSyncConfigurationBusiness.java:32)
	at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness$1.call(ScmSyncConfigurationBusiness.java:148)
	at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness$1.call(ScmSyncConfigurationBusiness.java:145)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.scm.ScmException: Error while executing command.
	at org.apache.maven.scm.provider.git.gitexe.command.GitCommandLineUtils.execute(GitCommandLineUtils.java:122)
	at org.apache.maven.scm.provider.git.gitexe.command.checkin.GitCheckInCommand.executeCheckInCommand(GitCheckInCommand.java:129)
	at org.apache.maven.scm.command.checkin.AbstractCheckInCommand.executeCommand(AbstractCheckInCommand.java:54)
	at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
	... 14 more
Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error inside systemOut parser
	at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:188)
	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:107)
	at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:74)
	at org.apache.maven.scm.provider.git.gitexe.command.GitCommandLineUtils.execute(GitCommandLineUtils.java:118)
	... 17 more
Caused by: java.lang.IllegalArgumentException: Illegal character in path at index 0: "jobs/ATS%20Testing/config.xml"
	at java.net.URI.create(URI.java:852)
	at org.apache.maven.scm.provider.git.gitexe.command.status.GitStatusConsumer.resolveURI(GitStatusConsumer.java:251)
	at org.apache.maven.scm.provider.git.gitexe.command.status.GitStatusConsumer.resolvePath(GitStatusConsumer.java:232)
	at org.apache.maven.scm.provider.git.gitexe.command.status.GitStatusConsumer.consumeLine(GitStatusConsumer.java:133)
	at org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:190)
	at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:135)
Caused by: java.net.URISyntaxException: Illegal character in path at index 0: "jobs/ATS%20Testing/config.xml"
	at java.net.URI$Parser.fail(URI.java:2848)
	at java.net.URI$Parser.checkChars(URI.java:3021)
	at java.net.URI$Parser.parseHierarchical(URI.java:3105)
	at java.net.URI$Parser.parse(URI.java:3063)
	at java.net.URI.<init>(URI.java:588)
	at java.net.URI.create(URI.java:850)
	... 5 more

I am seeing the same thing. Affects a lot of our jobs.

The same thing applies for user names. We encounter problems there at the moment due to GIT creating users from Commit Messages. So i think it is basically a thing with wrong URI encoding in SCM.

I'm seeing this as well. Using SCM Sync Configuration Plugin 0.0.9 and Jenkins version 1.642.3.
Despite this bug, this plugin is rad! Thanks!

We're being affected by this bug as well.
We get this error when it fails:

Any chance for a fix?
@ip2k @Zitrax @foundatron, how do you recover from this?

I came across this issue too and found out what the problem is.
The error is in the dependency maven-scm-provider-gitexe-1.9.1.jar

Illegal character in path at index 0: "jobs

says it all. The quote at char 0 breaks the whole thing. Meanwhile this has been fixed, but sadly no current release is up (even version 1.9.4 still has the error).
I cloned (git://git.apache.org/maven-scm.git), checked out tag 1.9.4 and fixed the error in file GitStatusConsumer.java
Then recompiled this lib and pushed it into the plugin scm-sync-configuration.hpi
This solved the problem for me.
Attached you find the patch
and the precompiled jar, which can be replaced into the hpi file.
Also for simplicity I attached the fully patched 0.0.9 of this plugin.

@christau, great work, many thanks!
I'll try it out tonight.

I have the same error. Job has %2F in name (slash from branch name - multibranch pipeline).
I create catalogue from error in checkoutConfiguration and manually commit it.
It resolves this problem, but I have to check with new branches.

@christau I sent this request to the Maven developers.  Any idea how to push it along?
http://mail-archives.apache.org/mod_mbox/maven-dev/201605.mbox/<CAG%3DrPVf6GP3tgXoaAGdru6bQ_CLONo%2BGQUcLPRWpDmP8KqGM7w%40mail.gmail.com>

Issue has been fixed in this Commit: https://github.com/apache/maven-scm/commit/68eecff6c782e18eb59840205c55d3d1631aa256
Fix should take part in upcoming release of maven-scm. Please update dependency in next release of scm-sync-configuration-plugin.

@jarmoni do you know when the release is happening?  Last I saw was this:
<EMAIL_ADDRESS>

@rodrigc No I haven't. I'm not related with maven-scm-team, just saw that issue has been fixed on Friday. I hope it won't take too long. Self-patched plugins in production-environment.....no good!

@christau Thanks for identifying the source of the problem.  maven-scm-team finally released a new maven-scm-provider-gitexe 1.9.5 plugin.  I updated the pom.xml here: https://github.com/jenkinsci/scm-sync-configuration-plugin/commit/63a7401520fcb7d65bacbdd35d8ff6bcb7bd1d80
In my testing, this seems to work.  Can you build the plugin and verify that jobs with spaces in their names can now be backed up?  I will rebuild the plugin.
@tomaswolf You previously provided this patch https://github.com/jenkinsci/scm-sync-configuration-plugin/commit/2f59c9d08f62e0479b7b6a553967275002dec259 which works around the fact that maven-scm-provider-gitexe had this bug: https://issues.apache.org/jira/browse/SCM-772
How does this fix affect the patch you provided?  Is it still needed?

@rodrigc, I just built a new HPI and i'm able to create and delete jobs with spaces in the name.

@mterzo thanks for the feedback.  Just to confirm, before the latest patch for SCM-772, were you unable to create/delete jobs with spaces in the name?

Yeah just checked out master and had no problem.

Hopefully https://github.com/jenkinsci/scm-sync-configuration-plugin/commit/a739a54d0c6d65c500245a46b0861cd6f1ba1cbf should fix the problem with Git