Unable to create VM Scale set in azure

Hi ,
While creating VM Scale set in Azure in UI and CLI i am getting error ,
Please find the below screenshot for your reference.

Thanks
Vardhan K

For that error i have tried to fix , but it showing that template is not valid according to the validation procedure,

Hi Vardhan,
i cant give exact fix but if you follow the below link once it may resolve your issue.
https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-invalid-template-errors

is this issue resolved ??

HI Ravi,
For the given link is for syntactical error explanation , but in my case i have tried it in UI, and cli , in the both cases i got the same error. i hope this will workout with Pay-As-you-Go , because i am on free trail.
Let me try with this and come back to you.
Thanks for the response.

Closing this issue as microsoft has to resolve this


How to complete userspace support for driver-specific API

tl;dr: we have not fully solved #11993.
PR #18186 documents an approach to driver-specific APIs based on extended a standard driver API with additional methods only supported by a specific driver API.  The requirements derive from #11993.
#12056 provided a macro to be used in system call verification to confirm that a driver-specific API call could be correctly called for a given device instance.  This approach lacked documentation and tests, but was merged.
Since it was never used in-tree, #23407 proposes removing it, in part because the solution is based on comparing the device's init function against an available symbol, and #23407 eliminates the init function from the device structure.
In attempting to assess whether the API can be removed, I've attempted to update #17631 to work correctly with user mode, which requires adding syscall implementations for its specific API.  This fails, because the syscall infrastructure doesn't support the architectural solution accepted in #18186.
To summarize the context:

The DS3231 driver is a specialized counter, conforming to the counter API but using an API table that includes additional functions.  A counter_driver_api instance appears at the start of the ds3231_driver_api.
While counter_driver_api is a top-level driver API and so is declared with __subsystem which triggers synthesis of K_OBJ_DRIVER_COUNTER ds3231_driver_api is not a top-level API, and does not have its own K_OBJ_DRIVER_DS3231 object type.  It cannot have such a type type, because the counter_foo() API is expected to work on devices that have ds3231_driver_api API tables.
We need some way to validate the system calls that are specific to the driver, which requires a change to Z_SYSCALL_SPECIFIC_API() to verify that the device is associated with the base API (so that the base API functions validate) and it must use the API table that provides the extended functions.

A proposed solution is presented in #24537.  I am not happy with it, particularly the dirty trick required to associate the base with extended API structures.
#17631 has been updated with a draft of what this would look like in a real driver.  Initial testing is promising, but the test application requires a lot of work to become fully userspace compatible.

@andrewboie please provide guidance.

@andrewboie we have kept this as an enhancement for now, but according to @pabigot it is currently not possible to give userspace support for driver-specific functions at all. If you could confirm that is the case, then we should change this into a bug.

@pabigot I'm really having trouble understanding why you need API struct abstractions for driver-specific APIs. I understand you invented this and am now having trouble with system calls.
The whole point of the API struct abstraction in our device model is so that many different drivers can all be programmed to the same subsystem interface.
What is the point of this API struct indirection when there is exactly ONE implementation, since these APIs are specific to one driver? This is totally unnecessary.
Defining a driver-specific syscall is easy. Here's an example. Let's say I want to add an API to the ns16550 driver:
In a header for ns16550 (not the main subsystem header):
__syscall int uart_ns16550_foo(struct device *dev, int bar);

In uart_ns16550.c:
int z_impl_uart_ns16550_foo(struct device *dev, int bar)
{
   .. do something ..
}

int z_vrfy_uart_ns16550_foo(struct device *dev, int bar)
{
    Z_OOPS(Z_SYSCALL_SPECIFIC_DRIVER(dev, Z_SYSCALL_DRIVER_UART, uart_ns16550_init)));

    return z_impl_uart_ns16550(dev, bar);
}

The verification function will not pass unless dev is a device instance of the UART subsystem, and its init function pointer matches uart_ns16550_init, guaranteeing that this is an instance of not just a uart driver, but an ns16550 driver.
What am I missing here? this works.

I don't know that you're missing anything.  What I was missing was this level of assistance back when I asked several times how to use the macro you provided, or when we discussed and got approved the solution documented in #18186.  It's quite likely I was distracted by the solution that seemed natural to me (i.e., nested vtables).
I'll see if I can make this work.  I do suspect the macro implementation needs to be fixed, though; it should not pass if it's a UART without also checking the init function.

What I was missing was this level of assistance back when I asked several times how to use the macro you provided

Peter I get literally hundreds of emails from GitHub a DAY. I do not read them all. If you can't figure out something you should try hitting me up on slack, or directly e-mailing me instead of whining like this.

when we discussed and got approved the solution documented in #18186.

I don't care who approved 18186. To be blunt: it belies a profound lack of understanding of why we have these vtables in the first place. To use them for singleton APIs is unnecessary boilerplate. I think it that PR should be deleted.

I do suspect the macro implementation needs to be fixed, though; it should not pass if it's a UART without also checking the init function.

It works just fine.
It returns an expression which first checks that the driver is the right type (the Z_SYSCALL_OBJ() part) and then checks that the dev->config->init function matches (the Z_SYSCALL_VERIFY_MSG() part). Did you not see where it checks the init function??? Help me out here

#define Z_SYSCALL_SPECIFIC_DRIVER(_device, _dtype, _init_fn) \
        ({ \
                struct device *_dev = (struct device *)_device; \
                Z_SYSCALL_OBJ(_dev, _dtype) || \
                        Z_SYSCALL_VERIFY_MSG(_dev->config->init == _init_fn, \
                                             "init function mismatch"); \
        })

Does that not check the driver is the right type OR that the init function matches?

#define Z_SYSCALL_SPECIFIC_DRIVER(_device, _dtype, _init_fn) \
        ({ \
                struct device *_dev = (struct device *)_device; \
                Z_SYSCALL_OBJ(_dev, _dtype) || \
                        Z_SYSCALL_VERIFY_MSG(_dev->config->init == _init_fn, \
                                             "init function mismatch"); \
        })

Does that not check the driver is the right type OR that the init function matches?

They return 0 on success

OK then. Thanks.


need info related to delete some images from task and need to merge tasks from different people's account to one task

My actions before raising this issue

[ ] Read/searched the docs
[ ] Searched past issues

Expected Behaviour

Current Behaviour

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Git hash commit (git log -1):
Docker version docker version (e.g. Docker 17.0.05):
Are you using Docker Swarm or Kubernetes?
Operating System and version (e.g. Linux, Windows, MacOS):
Code example or link to GitHub repo or gist to reproduce problem:
Other diagnostic information / logs:
Logs from `cvat` container

Next steps
You may join our Gitter channel for community support.
Hey
Actually I wanna train my data using yolov3. First I created a task on cvat using my account. Suppose uploaded 1000 images, annotated 700. Now I wanna delete these not labeled 300 images.
Next thing is due to burden, I gave 500 images to 4 different people each, so in total 2000 images. Now I've in total 5 output folders. How can I merge these 5 into 1 to train smoothly.

Hey
Actually, I wanna train my data using yolov3. First I created a task on cvat using my account. Suppose uploaded 1000 images, annotated 700. Now I wanna delete these not labeled 300 images.
Next thing is due to burden, I gave 500 images to 4 different people each, so in total 2000 images. Now I've in total 5 output folders. How can I merge these 5 into 1 to train smoothly.

Please consider using Datumaro product. You requirements out of CVAT responsibilities.


mcclient support for tarball archive load

Take output of https://github.com/mediachain/concat/issues/133 and load it via http API. Needs https://github.com/mediachain/concat/issues/134

added in #186


The tutorial page is gone?!

The video tutorial page is gone: http://framework7.io/tutorials/

There are tutorials available all the time, nothing changed or removed


Monte-Carlo Tree Search

Has anyone applied MCTS to the saturation phase, rather than trying to achieve full saturation?
I'm dealing with large expressions like
((z/(((((((((((((w+153)/2)/2)/2)/2)/2)+-5)*4)+9)/2)/2)+-5)*((((((((((((h+153)/2)/2)/2)/2)/2)+-5)*4)+9)/2)/2)+-5)))%64)

where the optimal form is something like
(z % ((h - 95) * (w - 95) / 16))

but it's nearly impossible to reach full saturation (in under an hour) because the graph explodes.
However if most of the branches are discarded, and only the N best are searched at each step, we can instead reach this result in under a second. MCTS isn't likely good for all possible languages, but for simple math I think it would work well.
I'll start working on an implementation and do a PR if it interests anyone.

@ezrosent is interested in this direction!

Also https://dl.acm.org/doi/10.1145/3578356.3592577 and https://arxiv.org/abs/2407.12794

I posted some in-progress work here. Seems very similar to what Max's students were up to, though I think the emphasis is a bit different. I'm more interested in using this method for when we don't have access to good per-node costs (e.g. when no linear cost model is suitable for the domain).
As for the initial post, I think the proposal is to use MCTS to find a good set of candidates to then use to prune the search space and continue searching a la beam search. I think this is another good idea!
Maybe this would be better in extraction-gym? That way we could potentially use it in egglog too without having to reimplement it.
Of course @jafioti if you have a reason to make this egg-specific one of us could go back and port it to extraction-gym as needed.

Thanks for all the suggestions! I'm doing a very simple MCTS implementation right now which sort of combines the saturation and extraction phases together to do a form of beam search.
For context, this work is for a deep learning compiler Luminal to simplify indexing expressions in GPU kernels. The goal for Luminal is to also use a similar technique applied across the entire graph of operators, where rewrites can take place on the whole graph, and some MCTS-based equality saturation is done to search for the fastest graph, and the cost function is either an approximate runtime estimator or the actual profiled runtime.
Right now I'm just going to make it the simplest implementation I could, specific to my index-expression use case, but I think generalizing it from there will be straightforward.

@ezrosent I've been looking in to egglog a lot. Its super cool and amazing how it generalizes egg and runs faster. I'd like to implement MCTS right on it, but it's pretty complex and doesn't have a good rust API yet. Would you recommend I just stick with egg for now and bring it over to egglog once it's pretty polished?

Great question! Took some time to talk to other egglog devs on this, and the answer is "egglog is the future but it's not super stable." If you're writing production code, I'd recommend egg for now, but if you need something (e.g. multipatterns) that egglog handles a lot better you are welcome to use egglog and we will work on supporting your use-case.
If you do want a good set of more stable APIs I'd recommend the python bindings; they're more stable and polished than interacting with it directly in Rust.

Closing since it's not a bug.


problems while installation of v0.14.1

First, thanks for this great product (though it's sad for a private use to see some of the great backup features being enterprise now)..
I get this error during the installation with helm3, according to the documentation:
timed out waiting for CRD: request to convert CR from an invalid group/version: kubedb.com/v1alpha1

It happens for both v0.14.0 and v0.14.1
When I run
 kubectl get apiservice | grep kubedb

I see among others:
v1alpha2.kubedb.com

but not v1alpha1

I've uninstalled everything from the 0.13 version, and removed also the postgres databases (data is persistent on storage).
Then I've installed v0.14.1 again and all works fine.


Bump version to 1.46.0-dev (on master branch)

Change was created by the release automation script. See go/grpc-release

failures: intermittent mac CI infra problems, and known interop test problems.


Support for Oculus/Meta Quest VR for N170 and other experiments

📝 Running the N170 experiment or other experiments using VR whilst wearing a Quest 2 VR headset
For example, should be able to run the N170 stimulus on the headset and collect valid eeg data, then be able to analyze and visualize it afterwards.
Example of steps used:

Turn on and place the Meta Quest 2 VR headset onto the head.
Turn on and place the OpenBCI Cyton EEG headset on top with a configured montage of: [FC1,FC2,CP5,CP6,P3,P4,PO3,PO4] with A1,A2 ground&reference.
Ensure the Quest 2 horizontal headset strap is running safely between(not underneath) the P3,P4 and O1,O2 electrodes.
Connect Quest 2 to windows via air link or link cable.
Use the built-in Oculus desktop app to access the Windows desktop and run the n170 eeg-notebooks experiment from command line or IDE(00x__n170_run_experiment.py).
Open the n170 analyzer/visualizer notebook(01r__n170_viz.ipynb) to check the response from the electrodes.
Repeat steps 5 and 6 until adequate data is captured and a negative 170ms(approx) response has been recorded.

Other experiments can have VR added too.

Load/prepare stimulus in the same function as previously (def load_stimulus(self))
Present stimulus in the same function as previously(def present_stimulus(self, current_trial: int))
VR can be enabled for the experiment as part of an initializer to the base Experiment class, by default it is not enabled(use_vr=False) and will function the same as previously before VR functionality was added.

If you'd like to see this feature implemented, add a 👍 reaction to this post.

Initial support has been merged to the develop branch, so closing this issue.


updated the html file according to the Javascript integration

updated the HTML code in index.html file according to the Javascript integration

Very happy with the html, just css to go now yayy


[SPARK-31361][SQL] Rebase datetime in parquet/avro according to file metadata

What changes were proposed in this pull request?

This PR adds a new parquet/avro file metadata: org.apache.spark.legacyDatetime. It indicates that the file was written with the "rebaseInWrite" config enabled, and spark need to do rebase when reading it.
This makes Spark be able to do rebase more smartly:

If we don't know which Spark version writes the file, do rebase if the "rebaseInRead" config is true.
If the file was written by Spark 2.4 and earlier, then do rebase.
If the file was written by Spark 3.0 and later, do rebase if the org.apache.spark.legacyDatetime exists in file metadata.

Why are the changes needed?

It's very easy to have mixed-calendar parquet/avro files: e.g. A user upgrades to Spark 3.0 and writes some parquet files to an existing directory. Then he realizes that the directory contains legacy datetime values before 1582. However, it's too late and he has to find out all the legacy files manually and read them separately.
To support mixed-calendar parquet/avro files, we need to decide to rebase or not based on the file metadata.
Does this PR introduce any user-facing change?

No
How was this patch tested?

Updated test

cc @MaxGekk @dongjoon-hyun @HyukjinKwon

Test build #120876 has started for PR 28137 at commit 8295549.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/25568/
Test PASSed.

Could you update the PR description? It should be >= 3.0 instead of > 3.0.

Do not rebase datetime values when reading parquet/avro, if we know the file written version and it's > "3.0".

I haven't looked at the implementation yet but the description looks dangerous for me:

always write the datetime values to parquet/avro without rebasing

@cloud-fan I think there are at least 2 cases:

Spark 3.0 saves parquets that are supposed to be loaded by Spark 3.0 - no need to rebase
Spark 3.0 saves parquets that should be loaded by Spark 2.4, 2.3 and etc. - need to rebase.

Do you think the seconds case is not possible?

Do not rebase datetime values when reading parquet/avro, if we know the file written version and it's > "3.0"

but you don't know the purpose of written files. Maybe an users wants to save parquet files by Spark 3.0  and read them back by Spark 2.4? For example, Spark 3.0 and Spark 2.4 can be used in different clusters that prepares data for each others.

Test build #120876 has finished for PR 28137 at commit 8295549.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class AvroDeserializer(rootAvroType: Schema, rootCatalystType: DataType, rebaseDateTime: Boolean)
class ParquetReadSupport(

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/120876/
Test PASSed.

@MaxGekk It's always an option to ask users to upgrade software if some bugs are not fixed in earlier versions. For example, if Spark 3.0 writes Parquet files and Spark 2.4 may read wrong data, we can ask them to upgrade to Spark 3.0. Forward compatibility is not officially supported.
On the other hand, if Spark 2.4 writes Parquet files and Spark 3.0 may read wrong data, asking users to downgrade is not a good option. This PR tries to improve backward compatibility by rebasing datetime more smartly: don't rely on the config if the file written Spark version is known. I think it's more important than forward compatibility.

For example, if Spark 3.0 writes Parquet files and Spark 2.4 may read wrong data, we can ask them to upgrade to Spark 3.0. Forward compatibility is not officially supported.

but before you removed the SQL config spark.sql.legacy.parquet.rebaseDateTimeInWrite.enabled, it was possible. After this PR, we force users to upgrade all theirs clusters to Spark 3.0, so, partial migrations won't be possible.

Partial upgrade is still possible, e.g. write files using 2.4 and read using 3.0. It's not possible to do the opposite though, as forward compatibility is not guaranteed. And that config doesn't really help too much with the forward compatibility: it's hard for users to know when to enable that config.

It's not possible to do the opposite though, as forward compatibility is not guaranteed.

@cloud-fan I would propose to write value of spark.sql.legacy.parquet.rebaseDateTimeInWrite.enabled to Parquet/Avro meta. So, Spark 3.0 could check the flag in read and decide either do rebasing or skip it. If the flag does not present in meta info (saved by Spark 2.4), just do rebasing.

Please see https://github.com/apache/spark/pull/28137#discussion_r404582477
My point is: it's more of an artificial use case and I'm not sure it worth introducing a new metadata key for it.

Test build #121326 has started for PR 28137 at commit 2e908c5.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/26009/
Test PASSed.

Test build #121326 has finished for PR 28137 at commit 2e908c5.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class AvroDeserializer(rootAvroType: Schema, rootCatalystType: DataType, rebaseDateTime: Boolean)
class AvroSerializer(
class ParquetReadSupport(

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/121326/
Test PASSed.

Test build #121576 has started for PR 28137 at commit 6905247.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/26256/
Test PASSed.

Test build #121576 has finished for PR 28137 at commit 6905247.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/121576/
Test PASSed.


When will there be a new stable version

As the title, I don't remember where I saw you mention that a new version would be released last week, but so far, it seems that we haven't seen the new version.
Thank you for what you have done.

We can't mention a specific date but I can ensure that in this month we will release the prod version.


proto: fix quadratic behavior in nested map marshaling

If the value of a map is a message with nested maps, calling valSizer in marshal may be quadratic -- it will call size at each level. Fix by using cached size if the value type is message.
Benchmark results with @LMMilewski's test case from https://github.com/golang/protobuf/issues/624:
name   old time/op    new time/op    delta
1-12     1.96µs ±19%    1.76µs ±18%     ~     (p=0.075 n=10+10)
2-12     5.10µs ± 6%    3.84µs ± 8%  -24.69%  (p=0.000 n=9+10)
4-12     14.2µs ±12%     8.2µs ±15%  -42.77%  (p=0.000 n=10+10)
8-12     43.0µs ±10%    15.6µs ±11%  -63.81%  (p=0.000 n=9+10)
16-12     138µs ±12%      33µs ±17%  -76.32%  (p=0.000 n=10+10)
name   old alloc/op   new alloc/op   delta
1-12       376B ± 0%      376B ± 0%     ~     (all equal)
2-12       928B ± 0%      752B ± 0%  -18.97%  (p=0.000 n=10+10)
4-12     2.54kB ± 0%    1.49kB ± 0%  -41.51%  (p=0.000 n=10+10)
8-12     7.89kB ± 0%    2.96kB ± 0%  -62.47%  (p=0.000 n=10+10)
16-12    27.0kB ± 0%     5.9kB ± 0%  -78.11%  (p=0.000 n=10+10)
name   old allocs/op  new allocs/op  delta
1-12       12.0 ± 0%      12.0 ± 0%     ~     (all equal)
2-12       28.0 ± 0%      23.0 ± 0%  -17.86%  (p=0.000 n=10+10)
4-12       75.0 ± 0%      45.0 ± 0%  -40.00%  (p=0.000 n=10+10)
8-12        229 ± 0%        89 ± 0%  -61.14%  (p=0.000 n=10+10)
16-12       777 ± 0%       177 ± 0%  -77.22%  (p=0.000 n=10+10)
Fixes #624.

I'd appreciate if this went in -- any news? Can I help this in any way?

@cherrymui, are you done or shall I merge?

Yes, this is done. You can submit this. Thanks!


Bump mirror image

Description:

Related issue(s):
Fixes #
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Codecov Report
Base: 74.16% // Head: 74.19% // Increases project coverage by +0.02% :tada:

Coverage data is based on head (9b653a0) compared to base (1f9b860).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #894      +/-   ##
==========================================
+ Coverage   74.16%   74.19%   +0.02%
==========================================
  Files          29       29
  Lines        1827     1829       +2
  Branches      339      341       +2
==========================================
+ Hits         1355     1357       +2
  Misses        374      374
  Partials       98       98

Impacted Files
Coverage Δ

packages/relay/src/lib/eth.ts
82.90% <0.00%> (+0.05%)
:arrow_up:

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

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


Customize WDECCardFieldScanner to skip security code entry

Some transactions like .tokenize does not need security code for the transaction. Nonetheless, current UI (WDECCardFieldScanner etc) requires security code entry to be there.
As a matter of fact, you can set the requirement explicitly off like this,
payment.isSecurityCodeRequired = false

but I don't find the counter part for UI in the version 4.0. It would be nice if we can customise the UI as well.

Hi @yfujiki ,
it is nice enhancement. but we are busy with other topics.
I will keep it opened.
I can advise to use transaction type .authroizationOnly. It has an advantage - it verifies card with issuer and you can be sure that card is valid.
Best,
Stefan


Optionally enable GZIP encoding with sslsplit

It appears that sslsplit by default strips all "Accept-Encoding" headers preventing content encoding features from working. This can create a problem for some misbehaving web servers and prevents SSLSplit from being truly transparent.
Is it possible to add functionality to optionally enable gzip. I know this would likely cause the log to contain binary content, but that can be handled by a third party implementor who parses this log.
Thoughts?

SSLsplit is transparent in that it doesn't operate as a proxy configured in the client (browser) but instead intercepts regular connections from the network.
Does using an ssl proxyspec instead of https work for your use case perhaps? In that mode there are no modifications of the transmitted data.

Also, can you be more specific on the «problems for some misbehaving web servers» that you mention?

Unfortunately ssl proxyspec will not work for us (if my understanding of the code is correct) because our objective is to capture HTTP Application data inside SSL. We process the HTTP connections from a named pipe. It appears as though the primary purpose of using the HTTP proxyspec is to eliminate HSTS and HPKP headers, both are necessary for our application.
In this particular case a web server that a user is connecting with required GZIP encoding to function properly. While I agree that the server should be modified to work in either scenario, some of these problems exist in the real world and since the majority of browsers Accept-Encoding: gzip by default they are easily ignored.
What problems does keep the Accept-Encoding header intact introduce? It seems to shortcut the extra processing overhead of unzipping the content, any other concerns?

No concerns except for the not human readable raw logs produced by sslsplit; postprocessing can fix that. To answer your question: the raison d'etre of the HTTP mode was originally just disabling connection persistency, chunking and pipelining in order to get away with a simplistic HTTP parser. Secondary functionality was to produce readable logs by disabling compression. HSTS and HPKP countermeasures came much later down the road.
Does changing "Accept-Encoding: " to "XXXXXX-Encoding: " in the strncasecmp() in pxyconn.c help in your use case? I'd like a confirmation that this is sufficient for your use case before I add yet another flag to the already sizable collection of option flags.


Router handling prefix incorrectly when using Jetty server

If I use a Router where the prefix includes a forward slash, I would expect the whole prefix to be stripped from the request before matching on the inner routes. More specifically, if I have routes like this:
org.http4s.server.Router(
  "pref-a/pref-b" -> myRoutes
)

And I make a request to pref-a/pref-b/my-resource, I would expect to be able to match Root / "my-resource" within myRoutes.
This appears to work as expected if I use blaze as the server, but if I use jetty it only removes the first segment of the prefix, meaning that I have to match Root / "pref-b" / "my-resource".
Not sure how good a job I did explaining that, so I have reproduced it in this repo. It spins up jetty on 8080 and blaze on 8081 serving the same routes. You can see that we get the expected behaviour from blaze but not from jetty.

This issue has been fixed in 0.22.9 / 0.23.8 (https://github.com/http4s/http4s/pull/5793).