SCP-2457: new API so select can only be applied to contracts that wait

Pre-submit checklist:

Branch

[ ] Commit sequence broadly makes sense
[ ] Key commits have useful messages
[ ] Relevant tickets are mentioned in commit messages
[ ] Formatting, materialized Nix files, PNG optimization, etc. are updated

PR

[ ] Self-reviewed the diff
[ ] Useful pull request description
[ ] Reviewer requested

Pre-merge checklist:

[ ] Someone approved it
[ ] Commits have useful messages
[ ] Review clarifications made it into the code
[ ] History is moderately tidy; or going to squash-merge

I wonder if you could update the PR description with short description (i.e. description copied from Jira) - I think I'm struggling with something like this as well (Trace just hanging and eating all my memory after a while) but I'm not sure what does contracts that wait really mean - is this a contract waiting for endpoint call?
(few minutes later after taking the time to read the PR) - it looks like it's exactly the case as endpoint now turns the return type to Waited - https://github.com/input-output-hk/plutus/pull/3558/files#diff-c58aeb2f43d03b879e7653c031ff1329b46b0df90277c0286ceaf359678d16dfR339)
I guess this is also related to weird Game behavior we are observing with plutus-starter in #3526.
p.s.: I find it a bit hard to follow Plutus development as it is quite rapid, there's no changelog and lots of PRs are relevant for just Marlowe - I don't want to create an Issue which makes changelog mandatory and give you even more work at this busy times but I could dedicate some time to writing one which could be helpful for others trying to follow - are there are any plans/timeline for release, tags and changelog and also would you accept a community maintained one if not?

@sorki : In the Contract API we currently have some functions that return immediately (for example currentSlot or balanceTx), and other functions that wait for a while until an event happens (awaitSlot, endpoint, awaitTxConfirmed, etc). If you mix waiting and non-waiting ones using select, then the non-waiting one will always return immediately, which is not very intuitive. So this PR fixes that by changing the types of select, awaitSlot etc.

are there are any plans/timeline for release, tags and changelog and also would you accept a community maintained one if not?

Yes we're aware that the changes we're making cause problems for everyone who is using Plutus already. Right now we are focused on getting everything ready for the initial release, but when that is out the door we will adopt a more user-friendly release process with changelogs, tags, etc.

Makes sense, thank you @j-mueller !


.js comment in Declaration Merging should be .ts (Issue #562)

Fixes #562

The use of .js here is intentional. it describes a code pattern in JS and then how it can be modeled in a TS.

Ah, thanks. That clarifies.


Arnej/add generic peek instruction

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.
@havardpe please review

@havardpe PTAL


🚀 [REQUEST] - Handle user leave in the middle

Describe

[x] When the user presses F5, redirect to main page. Also, don't forget to alert first.
[ ] Prevent history pop

Reasons
If you refresh in the middle of the step, all working tree goes away. And the active step goes back to step1.
How to Implement Features
No response
Additional Explanation
No response
Connection

[ ] Have no effect on other functions
[ ] Other functions need to be changed

using recoil persist, we could prevent header information from being deleted on refresh.
But now it caused #83 issue again. The issue produced here, so I'll fix it here.


Add .eslintignore file and ignore rules

@milesj
Are you open to adding an .eslintignore temporarily during the migration to ES6 so that eslint will not report errors for directories we have not migrated yet? We can remove the rules when we're finished.
I have editor integration enabled for eslint and all the lint errors in the old code are a little bit distracting :P

Good idea 👍


GitHub Issues Command

Usage: ?issues <username>/<repository>
As a: user
I want to: get a list of issues for a specific repository
So that I: can see them in Discord

This will require updating the GitHubService so that it has a new method, getIssues(), which returns an array of GitHubIssues (this will require a new interface).
When executing the command, an embed should be sent with the 3 most recent issues:

I can add it to the bot


Segmentation fault (core dumped)

I'm getting this issue after onClose connection
PHP version = 7.0.8-0ubuntu<IP_ADDRESS>
PHP memory limit = 900M
Operating system = Ubuntu 16.04
Libevent version = 2.0.22-stable
Libevent php = https://github.com/expressif/pecl-event-libevent (Reference)
Using libevent consider following log
New connection! (123)
New connection! (131)
New connection! (139)
Connection 123 has disconnected
Segmentation fault (core dumped)

Here as we can see it's stopping execution onClose and throws "Segmentation fault (core dumped)" message.
If I try without libevent then it's disconnecting clients and execution not stopping after onClose.
Sometime I'm getting following warning on onClose connection
PHP Warning: Unknown list entry type (0) in /vendor/react/event-loop/src/LibEventLoop.php on line 106

It seems the libevent extension does not support PHP 7 yet. I'd suggest using event instead as it supports PHP 7.


Minor style change in docs/index.md

Minor style change :fireworks:

Thanks for the contribution! ❤

Thanks for the contribution! ❤


Incompatibility with BetterSprayPaint

BetterSprayPaint conflicts with this mod and does not allow multiplayer to load correctly. Singleplayer works fine but when trying to join multiplayer games with the same two mods, the players trying to join will just get a dim black screen. Removing betterspray fixes the issue. It would be great to see compatibility with this mod since betterspray is pretty essential to use spray cans in the game

Maybe better spray had some custom moons fixes and now it is just fine? I will test at some point.

Fixed in latest


NAVER.MYBOX version <IP_ADDRESS>

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

I am stuck on this prompt and the application doesn't install when I press on the "OK" button:

You can't install 32bit version in 64bit Windows.

You can't install 32bit version in 64bit Windows.

Is there not a x64 download link? Most people are using the 64-bit version of Windows.

Please see the latest comment.

added 64bit in previous commit. Sorry for inconvenience.


Open shell singlet UHF/UKS calculations

Hello,
I am trying to perform open-shell UHF calculation on H2. I try to force this solution by imposing symmetry and spin to each spinorbital (one alpha electron in A1g and one beta electron in A1u) with the irrep_nelec method. However, this directive seems to be ignored and we return to the ground state closed shell singlet after execution.
Is it possible to obtain this kind of open shell singlet solution with symmetry and spin restriction only at the HF (or DFT) level. I am probably missing something here.
`#H2 Singlet open shell
h2_s2 = gto.Mole()
h2_s2.verbose = 4
h2_s2.atom = [
["H", (0., 0.,  2.5)],
["H", (0., 0., -2.5)],]
h2_s2.spin = 0
h2_s2.symmetry = True
h2_s2.irrep_nelec = {'A1g':(1,0), 'E1gx': (0, 0), 'E1gy': (0, 0),'A1u' : (0,1),'E1uy': (0, 0),'E1ux': (0, 0)}
h2_s2.basis = 'cc-pvdz'
h2_s2.build()
#UHF Singlet
mf = scf.uhf_symm.SymAdaptedUHF(h2_s2)
mf.kernel()
mf.get_irrep_nelec()`

h2_s2 = gto.Mole()
h2_s2.verbose = 4
h2_s2.atom = [
["H", (0., 0., 2.5)],
["H", (0., 0., -2.5)],]
h2_s2.spin = 0
h2_s2.symmetry = True
h2_s2.basis = 'cc-pvdz'
h2_s2.build()
mf = h2_s2.UHF()
mf.irrep_nelec = {'A1g':(1,0), 'E1gx': (0, 0), 'E1gy': (0, 0),'A1u' : (0,1),'E1uy': (0, 0),'E1ux': (0, 0)}
mf.kernel()

Thank you !


Type errors on updateOne/upsert when schema contains array

If I create a schema that contains an array, I get an error when trying to use $set within updateOne or upsert. See below to reproduce.
const clubhouseSchema = schema(
	{
		location: types.string({ required: true }),
		mapName: types.string({ required: true }),
		title: types.string({ required: true }),
		contractName: types.string({ required: true }),
		contractAddress: types.string({ required: true }),
		traits: types.array(types.number),
	},
	{
		timestamps: true,
	},
);

export type ClubhouseDoc = (typeof clubhouseSchema)[0];

const Clubhouse = papr.model('clubhouses', clubhouseSchema);
export default Clubhouse;

const result = await Clubhouse.upsert(
			{
				mapName: clubhouse.mapName,
			},
			{
				$set: {
					location: clubhouse.location,
				},
			},
		);

I get the following error on $set:

TS2322: Type '{ location: string; }' is not assignable to type 'PaprMatchKeysAndValues<{ createdAt: Date; updatedAt: Date; _id: ObjectId; location: string; mapName: string; title: string; contractName: string; contractAddress: string; traits?: ((options?: Options | undefined) => GetType<...>)[] | undefined; }>'.   Type '{ location: string; }' is not assignable to type 'PaprArrayElementsProperties<{ createdAt: Date; updatedAt: Date; _id: ObjectId; location: string; mapName: string; title: string; contractName: string; contractAddress: string; traits?: ((options?: Options | undefined) => GetType<...>)[] | undefined; }>'.     Property 'location' is incompatible with index signature.       Type 'string' is not assignable to type 'undefined'.
mongodbTypes.d.ts(143, 5): The expected type comes from property '$set' which is declared here on type 'PaprUpdateFilter<{ createdAt: Date; updatedAt: Date; _id: ObjectId; location: string; mapName: string; title: string; contractName: string; contractAddress: string; traits?: ((options?: Options | undefined) => GetType<...>)[] | undefined; }>'

If I delete the traits array from the schema, the error goes away.

I can't reproduce that error with the code you posted. I suspect it may be related to your TS version or tsconfig.json options. Can you please share those?

Ah, you are right. I am currently on Typescript 4.2.4. Upgrading to 4.9.5 removes the error. Thanks!


Unable to buy Whirls due royalties?

Unable to buy Whirls. I would not introduce royalties for upcoming drops until it is working flawlesly

Same

#8630

hotfix to send ed to the wallet?

hotfix to send ed to the wallet?

I guess so lol but if artist "accidentally" send its away, it shutdowns trading again 😄

@yangwao https://statemint.subscan.io/extrinsic/0x79387d2e75b9cf6e202e48e84e6f3522e703fc3f58a7b0c79f5d7134ea1b1be6
now we can sweep

I guess so lol but if artist "accidentally" send its away

he wont


Some az functionapp commands don't work for Flex Consumption SKU

Describe the bug
When using the Flex Consumption SKU, some commands get an error message citing an API version issue. An example of this is when assigning a user-assigned identity to the function app (either during creation or after creation).
This seems like it should work for any command which does a GET-modify-PUT loop from the App Service / Functions commands. It does not impact specific Flex Consumption commands, presumably because they use an alternative path. The issue seems to be for shared commands.
Related command
az functionapp identity assign --resource-group <groupName> --identities <uami> --name <appName>--debug
Errors

Site.FunctionAppConfig is invalid.  It is only supported for 2023-12-01 api-version or newer

Issue script & Debug output
Truncated to relevant response content:
cli.azure.cli.core.sdk.policies: Response content:
cli.azure.cli.core.sdk.policies: {"Code":"BadRequest","Message":"Site.FunctionAppConfig is invalid.  It is only supported for 2023-12-01 api-version or newer.","Target":null,"Details":[{"Message":"Site.FunctionAppConfig is invalid.  It is only supported for 2023-12-01 api-version or newer."},{"Code":"BadRequest"},{"ErrorEntity":{"ExtendedCode":"51021","MessageTemplate":"{0} is invalid.  {1}","Parameters":["Site.FunctionAppConfig","It is only supported for 2023-12-01 api-version or newer."],"Code":"BadRequest","Message":"Site.FunctionAppConfig is invalid.  It is only supported for 2023-12-01 api-version or newer."}}],"Innererror":null}
cli.azure.cli.core.azclierror: Traceback (most recent call last):
  File "/usr/lib64/az/lib/python3.9/site-packages/knack/cli.py", line 233, in invoke
    cmd_result = self.invocation.execute(args)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 666, in execute
    raise ex
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 733, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 703, in _run_job
    result = cmd_copy(params)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 336, in __call__
    return self.handler(*args, **kwargs)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
    return op(**command_args)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/command_modules/appservice/custom.py", line 1288, in assign_identity
    webapp = _assign_identity(cmd.cli_ctx, getter, setter, identity_role=role, identity_scope=scope)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/arm.py", line 721, in assign_identity
    resource = setter(resource)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/command_modules/appservice/custom.py", line 1283, in setter
    poller = _generic_site_operation(cmd.cli_ctx, resource_group_name, name, 'begin_create_or_update',
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/command_modules/appservice/_appservice_utils.py", line 21, in _generic_site_operation
    if extra_parameter is None else operation(resource_group_name,
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/core/tracing/decorator.py", line 76, in wrapper_use_tracer
    return func(*args, **kwargs)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/mgmt/web/v2023_01_01/operations/_web_apps_operations.py", line 17008, in begin_create_or_update
    raw_result = self._create_or_update_initial(
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/mgmt/web/v2023_01_01/operations/_web_apps_operations.py", line 16870, in _create_or_update_initial
    raise HttpResponseError(response=response, model=error, error_format=ARMErrorFormat)
azure.core.exceptions.HttpResponseError: Operation returned an invalid status 'Bad Request'
Content: {"Code":"BadRequest","Message":"Site.FunctionAppConfig is invalid.  It is only supported for 2023-12-01 api-version or newer.","Target":null,"Details":[{"Message":"Site.FunctionAppConfig is invalid.  It is only supported for 2023-12-01 api-version or newer."},{"Code":"BadRequest"},{"ErrorEntity":{"ExtendedCode":"51021","MessageTemplate":"{0} is invalid.  {1}","Parameters":["Site.FunctionAppConfig","It is only supported for 2023-12-01 api-version or newer."],"Code":"BadRequest","Message":"Site.FunctionAppConfig is invalid.  It is only supported for 2023-12-01 api-version or newer."}}],"Innererror":null}

cli.azure.cli.core.azclierror: Operation returned an invalid status 'Bad Request'
az_command_data_logger: Operation returned an invalid status 'Bad Request'

Expected behavior
The command should complete without errors as it does for other SKUs.
Environment Summary
This was originally found using Cloud Shell (below), but seems to also reproduce on 2.66.
az --version
azure-cli                         2.65.0 *

core                              2.65.0 *
telemetry                          1.1.0

Extensions:
ai-examples                        0.2.5
containerapp                      0.3.53
ml                                2.30.1
ssh                                2.0.5

Dependencies:
msal                              1.31.0
azure-mgmt-resource               23.1.1

Additional context
I believe this to be rooted in the version of azure-mgmt-web being referenced. The current version is 7.2.0 (from 2023-11-19). The latest version is 7.3.1 (from 2024-08-19). With the newer version, the default version will move to 2024-04-01, which should be tolerated.

route to service team

Hi @mattchenderson,
2.65.0 is not the latest Azure CLI(2.66.0).
If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

I can repro the same errors on 2.66 on my local laptop. The 2.65 errors I saw were in cloud shell.


[WFCORE-5956] Align Jakarta Authorization and Authentication versions…

… on wildfly-core-jakartaee with the ones used on WildFly Preview
Jira issue: https://issues.redhat.com/browse/WFCORE-5956

Core -> Full Integration Build 11704 outcome was UNKNOWN using a merge of 916648eab6a8d605fd27914fb4ff3a7e50782514
Summary: Canceled (Tests passed: 6325, ignored: 114; exit code 143 (Step: Build & test full (Maven)) (new)) Build time: 02:42:18

@darranl Right, yes, good point, I updated it as well to sync it with WildFly


General Data Persistence Issues

Feed doesnt know that I followed/unfollowed someone after clicking into their detail page.
Play progress doesnt update at the bottom of the screen

LOL we don't persist data. Something we're working on.


Uploading pictures doesn't work

Tried uploading all types of pictures and nothing will upload! Please help! Im using an Ubuntu VPS

Something like.
Mixed Content: The page at 'https://site.ca/console/view:settings#option_group=shop/shipping/admin' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://site.ca/csrf'. This request has been blocked; the content must be served over HTTPS.

Hello,
Seems your site is loaded via http or you are using reverse proxy and the https headers are not detected
You can fix it by going into Settings->Advanced->Internal settings

And then select "Force https"

Also if you want to do it manually you can edit the file config/microweber.php

 'force_https' => true,

I believe this issues is file write permissions issue. The docker image is a bit of a mess and makes it hard to mount the http folder as a volume.


/all_updates 404

Using your login method, /all_updates returns a 404 error. We must use /log/all_updates however the results are completely different.

@ddaddy i know, ill be updating this soon.
Regards

Same thing in getMedia

https://github.com/mgp25/Snap-API/commit/6ad650ddd2562cd892090fa4bbe468e45e092b61
Regards


PubSub Subscriber with StreamingPull Suddenly Stops Regularly

This is a consistent problem for us and many others. My theory is that the server side hangs up in the middle of a keepalive and RpcException has IsRpcCancellation on the line linked below which shuts down the subscription.
Since we expect StartNew to continue to run and RPC connection issues to be resolved, this causes our workers to stop silently leaving us dead in the water.
https://github.com/googleapis/google-cloud-dotnet/blob/2e2659b8b970ba3e0cf2937f91016f1835fb4c0c/apis/Google.Cloud.PubSub.V1/Google.Cloud.PubSub.V1/SubscriberClientImpl.SingleChannel.cs#L232

Can you please share a minimal but complete project that would reproduce the problem? A console application should be fine. Note I understand your theory requires something specific to happen to trigger the issue, so I understand this repro project won't be able to consistently reproduce the problem, that's fine, still I'd expect it would reproduce it if we run it long enough. We need to see exactly how your code looks like, for instance, you mention StartNew but we don't have a StartNew method or type in Google.Cloud.PubSub.V1.

my apologies, I meant StartAsync. Will follow up with a sample console app.

We also did some metrics analysis and this seems to happen while there is a sharp spike in ModifyAckDeadline requests across all of our services. This specific service is shown below - it's dropping Number of open streaming pull requests.
This specific topic uses message ordering. At this time, the message ordering key is unique per message (filename since we're using Object Create triggers in GCS). It is also the only subscription where we see this issue. We have a change coming soon to make Ordering Key per file prefix instead.
Sample Code:
using Google.Api.Gax;
using Google.Cloud.PubSub.V1;

const string PROJECT_NAME = "myproject";
const string SUBSCRIPTION_NAME = "mysubscription";
var subscriberClientBuilder = new SubscriberClientBuilder
{
    Settings = new ()
    {
        FlowControlSettings = new FlowControlSettings(10,null),
    },
    SubscriptionName = new (PROJECT_NAME, SUBSCRIPTION_NAME)
};

var cts = new CancellationTokenSource();
var subscriber = await subscriberClientBuilder.BuildAsync(cts.Token);

var task = subscriber.StartAsync(async (message, ct) =>
{
    Console.WriteLine($"Message Received {message.MessageId}");
    if (ct.IsCancellationRequested) Console.WriteLine("Cancellation Requested");
    return await Task.FromResult(SubscriberClient.Reply.Ack);
});

Console.WriteLine("Waiting for Messages, Press any key to cancel and exit.");
Console.ReadKey();
cts.Cancel();

// Oddly, without StopAsync, StartAsync doesn't stop even though we called cancel on the ambient CTS.
await subscriber.StopAsync(cts.Token);
await task;

if (cts.Token.IsCancellationRequested) Console.WriteLine("StartAsync done because Cancelled!");
Console.WriteLine("DONE!");

relevant terraform:
resource "google_pubsub_subscription" "thesubscription" {
  name = "thetopicname"
  topic = "thetopic"

  ack_deadline_seconds = 600
  enable_message_ordering = true
  enable_exactly_once_delivery = true

  retry_policy {
    minimum_backoff = "60s"
  }
  dead_letter_policy {
    dead_letter_topic = google_pubsub_topic.thetopic-dlq.id
    max_delivery_attempts = 15
  }
}

Metrics showing dropoff of Streaming Pull connections over time until it finally dies all the way and we have to restart the service. The service runs as a GKE Deployment with 2 Replicas.
Streaming Pull dropping off over time. All subscriptions ModifyingAckDeadline:

Filtered modify ack deadline to the one subscription_id:

Dropoff and Ack Message count:

Given that last chart, I wonder if it's related to the unique OrderingKey per message more than anything. I saw that the code had a queue for Ordered messages, but it doesn't make sense that it would behave this way. When one message got pulled in with "File123" and is ACK'd then another comes with "File234" the first one is ACK'd so should no longer have an impact on ordering.
FWIW: we process 9 distinct files each day. Each have a distinct name from day to day. Each one may take 10-20 minutes to complete, hence the deadline extension.

Thanks for the code and the detailed explanation. One reamining question is which Google.Cloud.PubSub.V1 version are you using, exactly.
I'll try to get to this later today or tomorrow.

It seems we are still in the same situation even after changing the OrderingKey to file prefix "FileTypeA", "FileTypeB", ... instead of "FileTypeA_20240228" "FileTypeA_20240229", "FileTypeB_20240228",  "FileTypeB_20240229", ...
Every time the daily batch messages are processed (approx 9 individual files per day with 5 different file prefixes, originating from a batch of files uploaded to bucket), there are fewer open streaming pulls until eventually they stop altogether.
If it helps, some of the message processing requires a ModifyAckDeadline due to taking longer than 10 mins. Perhaps this is part of the problem, perhaps not.

Thanks for the extra info. I'll take a look as soon as I can but just for expectations it will probably be early next week.

Okay, I'm looking into this now - I'm afraid my experience with diagnosing Pub/Sub issues is that there'll be a lot of back and forth with various questions and tests before we get to the root problem. Thanks so much for all the info you've already provided.
I can explain one thing off the bat: the reason that cts.Cancel() isn't doing anything is that the cancellation token passed into BuildAsync is only used for the build task itself. Building a client involves obtaining a credential, which can involve network requests to a metadata server - the cancellation token allows you to cancel that. After the client has been created, that cancellation token is irrelevant.
Now, to understand your situation a bit better:

Am I right in saying you've just got one Pub/Sub message per file, so we're looking at just ~9 messages per day? Or are there multiple messages per file?
You're running on GKE: I assume that means Linux in this case? If you could let us know the distribution/version of Linux and the version of .NET you're using that would be great.
In terms of reproducing the problem:

Do you have a test cluster you're able to try this in? In particular, it would be really interesting to know if you see the same behavior on a shorter timescale, e.g. pushing 9 messages per hour instead of per day (but ideally still taking more than 10 minutes to process - using Task.Delay to simulate that, if necessary)
Are you able to run a test to try this from a local developer machine instead of on GKE? (There can be subtle differences between environments in terms of long-running network connections; if we can reproduce this outside GKE it would be really helpful.)
If you're able to run various tests, could you run one where ModifyAckDeadline isn't needed (e.g. just post ~9 nearly-empty files which can be processed and ACKed quickly)

All of this is just trying to play divide-and-conquer at the moment (and giving me enough information to reproduce the issue myself, which will massively reduce the back-and-forth). I don't have any concrete ideas about what's happening at the moment - but if I can reproduce the issue myself, I can easily add a load of logging etc.
I'm going to try a simple repro to start with of just starting a single client on my Windows box, using the same topic configuration that you've got, and occasionally adding messages to it, with a mixture of "needs modify ack deadline" and "ack quickly".

Okay, my simplest tests didn't show anything - which is pretty much what I expected. I'll try leaving the code running for multiple hours (if I can remember not to shut my laptop down!) before moving onto the next scenarios...

Nearly 24 hours later, the subscriber is still running fine, and the number of open streaming pull requests is stable (goes up and down a bit, as expected, but returns to the right level). I've sent large and small batches of messages, with a mixture of different simulated processing times. No joy reproducing the problem yet :(

Dropping in to add a very similar case we're encountering. We've got a few .NET apps on GKE that use the Pub/Sub queues. They're fairly high-volume queues - processing ~110k messages a day, peaking at around 3-4k messages an hour. It works fine on weekdays, but on weekends the number of messages published drops down a lot and we might get 1-2 an hour.
We recently updated the PubSub NuGet package from 2.9.x to 3.7.x. Since updating, we've noticed that the application seems to drop the connection to the Pub/Sub queue if there are no messages published in the last ~15 minutes or so. It seems fairly similar to this issue on the NodeJS lib - https://github.com/googleapis/nodejs-pubsub/issues/1135.
So far our workaround is to just restart it, but we are looking at something more automated if we can't land on a fix in the upstream library.

@Mihier-Roy: Are you able to reproduce the issue outside GKE? Given the mention of Docker boundaries in the linked NodeJS issue, I'm wondering whether I might be able to reproduce this in a "simple" Docker container. (Rather than having to deploy to GKE.) Will give it a try. Any more information you can provide would be really useful - see my earlier comments for the sort of thing I'm interested in. (If you could let us know your topic configuration too, that'd be great. Things like message ordering and exactly-once delivery have some interesting effects in terms of how the clients behave.)

@jskeet: I haven't tried to re-produce outside of GKE just yet, but I'll take a stab at it today/tomorrow! I hope it's something we can reproduce on a Docker container.
Some additional info:

We use the standard debian based .NET base image (.NET 7 at the moment) for deploying our apps on GKE
We do have a test cluster - I'll try reproducing the issue on there since the queue has a lot lower volume on it

As for topic configuration:

We don't have message ordering
We don't have exactly-once delivery

@philvmx1: Your new code is still somewhat confusing.
Firstly, the cancellation token here is pointless:
var subscriberCancellationToken = new CancellationToken();
var subscriber = await subscriberClientBuilder.BuildAsync(subscriberCancellationToken);

That's just equivalent to not passing in a cancellation token:
var subscriber = await subscriberClientBuilder.BuildAsync();

Secondly, this comment is pretty misleading in its current location:
// DO NOT USE THE CANCELLATION TOKEN THAT IS PASSED INTO THIS METHOD.
// We need a new cancellation token because the SubscriberClient can cancel the token itself. If the
// SubscriberClient cancels, we want to restart the subscription. The caller of ProcessMessages should re-invoke this
// method when it completes.

It looks like you're talking about the cancellation token passed into BuildAsync, but I'm guessing you actually mean the cancellation token passed to the delegate that's passed to subscriber.StartAsync... that's the cancellation token which SubscriberClient can (and should!) cancel, if the subscriber is being shut down.

However, since StartAsync doesn't take a cancellation token and we're awaiting, there doesn't seem to be a way to tell the subscriber client to stop.

The task returned by StartAsync will only complete when the subscriber has been asked to stop. It's a bit like WebApplication.RunAsync. It's not clear to me where you're calling StartAsync, but you quite possibly want to just keep hold of the task and await it on application shutdown. You could potentially do it in some kind of loop so that if the task completes in a faulted state due to some error, you restart the subscription - but I'd expect that in most cases such a fault would be permanently fatal and your application should fail at that point anyway.
Note that in your original code, when you were passing cts.Token into BuildAsync, nothing in the Pub/Sub code could cancel that token. It's a fundamental principle of .NET cancellation that a CancellationToken can only be used to observe a cancellation request - if you want to request cancellation, you need a CancellationTokenSource.

@philvmx1: Separately, regarding this:

one error was logged recently which may (or not) be related, this was after our fix was in place. We don't retain logs long enough to have any from before our fix.

That looks like it could very well be related. That certainly looks like it's a single channel failing - which would then (if I'm reading the code correctly) stop the whole SubscriberClient. So if your fix effectively changed how you were restarting SubscriberClient in the face of failure, then that could explain the previous behavior. (If you weren't restarting appropriately and now are.)
Of course, that just means that the next question is why you're seeing that exception. That's where it may be GKE-specific. I've tried a long-running task in plain Docker (not running on GCP) and it's working fine for me. I'd still be really interested in knowing whether you can reproduce the error at all when not running in GKE. Additionally, if you're collecting metrics about when you're restarting the SubscriberClient, and can compare that with the problems you were having before, that would be good to know about.

@jskeet I realized that the comment is not correct now that you've cleared up that the cancellation token in BuildAsync is not passed to the built client. It doesn't quite explain why it seems to have solve our problem. There must be something else. I'll look closely if anything else changed.
What I can't quite understand is how the client doesn't reconnect on its own after the other side hangs up.Or if it can't, why it wouldn't throw, in which case we would catch, log an error (which we never did see in the logs or this would have been much clearer to us) and StartAsync again - even in the old code.

Or if it can't, why it wouldn't throw

I believe that's what it is doing, effectively, by making the task returned by StartAsync complete in the faulted state. I would expect that's how you got the log entry you've got. (What other behavior would you expect from an async method?)
I would expect errors like this to usually indicate a fatal problem - something we wouldn't want to just retry, or at least not for long. (It's possible that there's already retry going on, although we normally don't retry for streaming calls.)
It's hard to say anything more until we can reproduce the failure though.

If StartAsync completed in any state, we should expect to see the Warning logged at the end of the following (our log level is >= Warning).
public async Task ProcessMessages<TEventHandler>(CancellationToken cancellationToken)
{
... snipped setup and BuildAsync code for brevity ....
        await subscriber.StartAsync(
            async (message, cancelToken) =>
            {
                try
                {
                  ... snipped for brevity ...
                    return await processor.ProcessMessage(message, handler.Handle, cancelToken);
                }
                catch (Exception e)
                {
                    _logger.LogError(e, e.Message);
                    throw;
                }
            });

        _logger.LogWarning($"PubSub listener for subscription {_config.SubscriptionName} has disconnected");
}

So how did you capture the log you included in https://github.com/googleapis/google-cloud-dotnet/issues/11793#issuecomment-1995807014? I'd assumed that was already from awaiting StartAsync.
Note that the code you've shown above wouldn't log a warning if StartAsync returned a task that was then faulted, because when you await the task that await expression would throw
Rather than getting snippets of code in various places, I'd really like to go back to a minimal but complete example which actually demonstrates the problem. It's not clear to me what you observed with the code in https://github.com/googleapis/google-cloud-dotnet/issues/11793#issuecomment-1967456165. Did you actually run that code and see the problem, or was it just meant to be sample code to show how you set things up? (It's really important that we end up with shared code which does definitely demonstrate the problem.)

Error should have been logged in the BackgroundWorker in https://github.com/googleapis/google-cloud-dotnet/issues/11793#issuecomment-1995807014 via _logger.LogError(e, e.Message);. Then it should loop around after the delay, build a new PubSub client and StartAsync again. The referenced log message is more recent, after removing the cancellationToken from BuildAsync.
Understood about the working sample, I am working on creating something that models the problem with much less abstraction. I do have test environments to run them in. What I don't have is a lot of dedicated time for this since I'm running a project with a fixed deadline. So I have to squeeze in time to try things, build isolated test code, and dig for additional information.
Digging into metrics in DataDog, found that each GRPC POST last 15 minutes until error. Interestingly, the number of errors tapers off over time. As does the number of requests.
Errors:

Requests

minimal problem model code I have so far:
using Google.Api.Gax;
using Google.Cloud.PubSub.V1;

Host.CreateDefaultBuilder(args)
    .ConfigureServices((b, s) => {
        s.AddLogging(
            x => x.AddSimpleConsole()
        )
        .AddHostedService<MessageHandler>();
    })
    .Build()
    .Run();

public class MessageHandler : BackgroundService
{
    const string PROJECT_NAME = "<your-project-id>";
    const string SUBSCRIPTION_NAME = "<your-sub-name>";
    private readonly ILogger _logger;
    private readonly SubscriberClientBuilder _builder;

    public MessageHandler(IServiceProvider sp)
    {
        _logger = sp.GetRequiredService<ILogger<MessageHandler>>();
        _builder = MakeBuilder();
    }
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation("ExecuteAsync");
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
        var subscriber = await _builder.BuildAsync(stoppingToken);
        _logger.LogInformation("subscriber.StartAsync");

        await subscriber.StartAsync(
            async (message, cancelToken) =>
            {
                try
                {
                    _logger.LogInformation("Message {}", message.MessageId);
                    if (stoppingToken.IsCancellationRequested) _logger.LogWarning("Cancelling stoppingToken");
                    if (cancelToken.IsCancellationRequested) _logger.LogWarning("Cancelling cancelToken");

                    await HandleMessage(message, cancelToken);

                    if (stoppingToken.IsCancellationRequested) _logger.LogWarning("Cancelling stoppingToken");
                    if (cancelToken.IsCancellationRequested) _logger.LogWarning("Cancelling cancelToken");

                    _logger.LogInformation("Acking {}", message.MessageId);
                    return SubscriberClient.Reply.Ack;
                }
                catch (Exception e)
                {
                    _logger.LogError(e, e.Message);
                    if (stoppingToken.IsCancellationRequested) _logger.LogWarning("Cancelling stoppingToken");
                    throw;
                }
            });
            }
            catch (Exception e)
            {
                _logger.LogError(e, e.Message);
            }

            await Task.Delay(1000, stoppingToken);
        }
    }

    private async Task HandleMessage(PubsubMessage message, CancellationToken cancelToken)
    {
        int delayMilliseconds = GetDelayFromMessage(message);
        _logger.LogInformation("Delay {} ms", delayMilliseconds);
        await Task.Delay(delayMilliseconds, cancelToken);
    }

    private static int GetDelayFromMessage(PubsubMessage message)
    {
        int delayMilliseconds = TimeSpan.FromMinutes(10).Milliseconds;
        if (message.Attributes.TryGetValue("delay", out string delayValue)
            && int.TryParse(delayValue, out int delayMinutes)
        ) delayMilliseconds = TimeSpan.FromMinutes(delayMinutes).Milliseconds;
        return delayMilliseconds;
    }

    private static SubscriberClientBuilder MakeBuilder()
    {
        var subscriptionName = new SubscriptionName(PROJECT_NAME, SUBSCRIPTION_NAME);
        var settings = new SubscriberClient.Settings
        {
            FlowControlSettings = new FlowControlSettings(
                maxOutstandingElementCount: 10,
                maxOutstandingByteCount: null)
        };

        var subscriberClientBuilder = new SubscriberClientBuilder
        {
            Settings = settings,
            SubscriptionName = subscriptionName
        };
        return subscriberClientBuilder;
    }
}

csproj
<Project Sdk="Microsoft.NET.Sdk.Worker">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Google.Cloud.PubSub.V1" Version="3.9.1" />
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="8.0.0" />
  </ItemGroup>

</Project>

Correction, our change did not solve the issue for us. With enough time, we are still seeing the downward stair step from Number of open streaming pulls.

Thanks - I'll get back to trying to repro this tomorrow morning.

Thank you! I've got one running on my machine now. 10 open streaming pulls. Had a small error in my sample code, needed TotalMilliseconds rather than Milliseconds.
If I can't repro either, will do some other things next week.

Just looking at the error handling code, we do stop and restart the pull request on errors we deem to be recoverable - on others we abort the whole subscriber (and return a faulted task). I tested this by deleting the subscription that was being used, and it faulted as expected. The error handling code is here.

After exploratory testing overnight and this morning, here are some interesting things I'm seeing:
The same message with 10 minute processing time being handled multiple times. This is the tail of the logs.
MessageHandler: Information: subscriber.StartAsync
info: MessageHandler[0]
      subscriber.StartAsync
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Net.Sockets.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Net.NameResolution.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Security.Cryptography.Primitives.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Collections.NonGeneric.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Security.Cryptography.Encoding.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Formats.Asn1.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Text.Encoding.Extensions.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Threading.Channels.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Runtime.CompilerServices.Unsafe.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Runtime.Intrinsics.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
info: MessageHandler[0]
      Message<PHONE_NUMBER>064735
MessageHandler: Information: Message<PHONE_NUMBER>064735
info: MessageHandler[0]
      Delay 600000 ms
MessageHandler: Information: Delay 600000 ms
MessageHandler: Information: Acking<PHONE_NUMBER>064735
info: MessageHandler[0]
      Acking<PHONE_NUMBER>064735
info: MessageHandler[0]
      Message<PHONE_NUMBER>064735
MessageHandler: Information: Message<PHONE_NUMBER>064735
info: MessageHandler[0]
      Delay 600000 ms
MessageHandler: Information: Delay 600000 ms
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Diagnostics.StackTrace.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Reflection.Metadata.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Loaded '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.11/System.Collections.Immutable.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
info: MessageHandler[0]
      Acking<PHONE_NUMBER>064735
MessageHandler: Information: Acking<PHONE_NUMBER>064735
info: MessageHandler[0]
      Message<PHONE_NUMBER>064735
MessageHandler: Information: Message<PHONE_NUMBER>064735
info: MessageHandler[0]
      Delay 600000 ms
MessageHandler: Information: Delay 600000 ms
info: MessageHandler[0]
      Acking<PHONE_NUMBER>064735
MessageHandler: Information: Acking<PHONE_NUMBER>064735
MessageHandler: Information: Message<PHONE_NUMBER>064735
info: MessageHandler[0]
      Message<PHONE_NUMBER>064735
MessageHandler: Information: Delay 600000 ms
info: MessageHandler[0]
      Delay 600000 ms

NOTE: I had to restart this morning because the client token expired overnight.
In Google Console, comparing ModifyAckDeadline to ExpiredAckDeadlines...

And the unack'd messages.

At this point, it seems like our issue is more closely related to timing or result of the ModAckDeadline requests, WDYT? To me it seems like ModAckDeadline is not happening, the ACK deadline is timing out, and the message(s) are being pulled over and over again.

Hmm... it does sound like that's feasible.
Can I check whether these were results you got from running your code locally or in GKE? (If you've managed to reproduce it outside GKE, that would be a major step forward.)
We can get more useful log information too:
Enable timestamps (and single line output)
    .ConfigureServices((b, s) =>
    {
        s.AddLogging(x => x.AddSimpleConsole(opt =>
        {
            opt.TimestampFormat = "yyyy-MM-dd'T'HH:mm:ss.FFF'Z' ";
            opt.SingleLine = true;
        }))
        .AddHostedService<MessageHandler>();
    })

Enable client-level logging
Change the constructor to:
    public MessageHandler(IServiceProvider sp)
    {
        _logger = sp.GetRequiredService<ILogger<MessageHandler>>();
        var clientLogger = sp.GetRequiredService<ILogger<SubscriberClient>>();
        _builder = MakeBuilder(clientLogger);
    }

Change the MakeBuilder method to:
    private static SubscriberClientBuilder MakeBuilder(ILogger clientLogger)
    {
        var subscriptionName = new SubscriptionName(PROJECT_NAME, SUBSCRIPTION_NAME);
        var settings = new SubscriberClient.Settings
        {
            FlowControlSettings = new FlowControlSettings(
                maxOutstandingElementCount: 10,
                maxOutstandingByteCount: null),
        };

        var subscriberClientBuilder = new SubscriberClientBuilder
        {
            Settings = settings,
            SubscriptionName = subscriptionName,
            Logger = clientLogger
        };
        return subscriberClientBuilder;
    }

... then add "Google.Cloud.PubSub.V1.SubscriberClient": "Trace" into appsettings.json.
That way we'll be able to see exactly when ModifyAckDeadline is being called, etc.

This is locally not in GKE.
A little ahead of you here, I've already added timestamps and additional info and restarted after restarting the service a couple times, it's acking some that have been unacked for many hours. Will add the tracing though, that's going to help a lot.
After restarting debug, it ended up acking a couple more that were stuck for a looong time. These were several messages with the same OrderingKey sent around the same time.
2024-03-15 15:24:55Zinfo: MessageHandler[0] Message<PHONE_NUMBER>068600 OrderingKey kyc PublishTime "2024-03-15T02:42:09.539Z"
2024-03-15 15:24:55Zinfo: MessageHandler[0] Delay 600000 ms
2024-03-15 15:25:25Zinfo: MessageHandler[0] Acking<PHONE_NUMBER>395937

Maybe you'd want to model the expired token in your own debugging session - when I reauthenticated using cgloud command, it did not pick up the new token. How often to tokens expire in GKE-land? Do they autorefresh every 24 hours or so? I saw error logs when this happened that we aren't seeing in prod, so it's probably a separate issue if anything.
It finally ack'd all messages but took restarting the program. This is essentially what we do in production too. I would say it kind of models the problem fairly well. How to actually make it fail on purpose is still a bit of a mystery though.
Adding Trace now and will give it another go with various OrderingKey and delay attributes. Might even disconnect my machine from the internet and reconnect to see what that does.

Tangentially:

Maybe you'd want to model the expired token in your own debugging session - when I reauthenticated using cgloud command, it did not pick up the new token. How often to tokens expire in GKE-land? Do they autorefresh every 24 hours or so? I saw error logs when this happened that we aren't seeing in prod, so it's probably a separate issue if anything.

Can you show exactly which credentials you are using in GKE and which credentials you are using locally. In general you shouldn't need to worry about access tokens expiring in neithre of these environments as we have credential types that will automatically refresh the token for you etc.

@amanda-tarafa it's gcloud auth application-default login locally. They probably should expire in that case.

@amanda-tarafa it's gcloud auth application-default login locally. They probably should expire in that case.

In GKE as well? Can you show how you are initializing the clients in both environments, basically what, if any, credentials are you passing to the SubscriberClientBuilder?

@amanda-tarafa We're using service credentials in GKE. 99% sure this was a "locally debugging using dev credentials" issue only and not an issue in GKE. As I mentioned, we didn't see any log entries in prod.

@amanda-tarafa We're using service credentials in GKE. 99% sure this was a "locally debugging using dev credentials" issue only and not an issue in GKE. As I mentioned, we didn't see any log entries in prod.

Ok, my point was then that you don't need to worry about tokens expiring in GKE, those will be refreshed automatically for you is you are using explicit service account credentials or default account credentials.
I'm also surprised that you have to re-authenticate locally when using gcloud auth application-default login (if you are using default application credentials to initialize the subscriber) as the credential generated by the gcloud command should include a refresh token that we use to refresh the access token. Again, if you can share how you are initiating the SubscriberClient I can then ask follow up questions to see what's happening there. And any info on why and when you had to re-authenticate locally? Why did you have to do this? Where you actually seeing authentication errors?

@amanda-tarafa I'm creating the client using the code shared in an above comment. look for MakeBuilder() and _builder.BuildAsync(. I don't think I have bandwidth to split between two topics with the time I have available. In any case, it seems unlikely that it's related to the issues we saw in our prod system at this point. I saw logs that said the token was expired locally but never in prod so I don't think that was the issue.

@philvmx1 I also think the token expiring is not related to your issues, I simply wante to address your previous comment:

Maybe you'd want to model the expired token in your own debugging session - when I reauthenticated using cgloud command, it did not pick up the new token. How often to tokens expire in GKE-land? Do they autorefresh every 24 hours or so? I saw error logs when this happened that we aren't seeing in prod, so it's probably a separate issue if anything.

If you are ever ready to look into why you need to re-authenticate locally, feel free to create a separate issue.

I was able to repro this issue from local process to GCP subscription.
I kept the subscriber program running over the weekend.
It logged the following message over and over again, so it looks like it's connecting.
2024-03-18 15:57:17Ztrce: Google.Cloud.PubSub.V1.SubscriberClient[0] Starting duplex streaming API call to StreamingPull.
2024-03-18 15:57:21Ztrce: Google.Cloud.PubSub.V1.SubscriberClient[0] Starting duplex streaming API call to StreamingPull.
2024-03-18 15:57:47Ztrce: Google.Cloud.PubSub.V1.SubscriberClient[0] Starting duplex streaming API call to StreamingPull.

I published a message and waited, but it did not get picked up for processing by the streaming pull. Then I published another, same thing. They're sitting unacked. No open streaming pull requests since March 16.

@philvmx1: Really glad we've been able to reproduce locally.
Do you still have the logs, and are you able to show more of the lines (e.g. about 30 of them)? I'd like to get a sense of the timing. (I'm also setting ClientCount=1 in the builder in my current tests, to try to make the logging simpler to understand.)
Also, just to go back to auth briefly - what auth were you using this time? I've got a sneaking suspicion about this, but I'm going to run some tests locally to confirm.
One thing I do want to do is add more diagnostics to the library - now that we've got ILogger integration, we should use it a lot more. I'm looking into that now...

I've made some potential progress, but I've got an odd situation in terms of credentials now which I don't think is due to the Pub/Sub library itself (I'm seeing invalid JWT grants). However, I have seen a situation where a subscriber appears to start but never makes progress. It's a bit of a mess at the moment, but I'm hopeful that by the end of the day we'll have more progress.

Okay, I know what was odd about the credentials: I had a service account key that had expired. I can now reproduce four different situations:

Application default credentials not available: building the SubscriberClient fails
Service account credentials have expired, default settings: StreamingPull fails with an RPC status of Unauthenticated, and the task returned by StartAsync fails quickly
Service account credentials have expired, but UseJwtAccessWithScopes = false is set to false: StreamingPull fails with an RPC status of Internal, which is deemed retriable, and we just retry, forever
Valid credentials: all works fine

My next step will be to try the same code with Compute credentials (which admittedly might be slightly different in GKE than other environments, but it'll be good to at least see).
I'll definitely be working on adding logging into SubscriberClient and PublisherClient. (Admittedly the log levels to use end up being slightly tricky to decide - if the library is going to "silently" retry, should we actually be logging an error, or just debug?) Additionally, we need to consider a retry policy that doesn't keep going forever.
Now, what I don't know yet is whether this is the situation you're facing. Please could you let me know:

What credentials you were using in your local test?
If I'm able to build a NuGet package with additional logging and attach it here, would you be able to use that for testing, or does it need to be something published to nuget.org? (We may be able to release a beta with logging within a few days to help with this, but I could create something locally rather quicker.)

So token stops refreshing for whatever reason, pull thinks it's working but it's actually failing silently forever. May or may not be the same issue in prod, but who knows. I'll see if there was any change to our credentials between the last time it failed there and when it started seemingly working again...although since the # of open pulls keeps dropping every day nearly at the 24 hour mark (token lifetime is how long again? ;) ), I'm thinking it's fragile at best.
I don't fully understand the question "What credentials..." but I'll give answering a try anyway. Locally, I'm logging in with my own credentials using gcloud auth application-default login
Well how about this...I came across the logs for gcloud and found many errors with refresh over the past several days. The first of these started around the same time the number of streaming pull requests dropped. We're finding all kinds of fun things!
2024-03-15.gcloud.log
First chunk from attached file until traceback starts
2024-03-15 11:04:11,114 DEBUG    root            Loaded Command Group: ['gcloud', 'auth']
2024-03-15 11:04:11,116 DEBUG    root            Loaded Command Group: ['gcloud', 'auth', 'print_access_token']
2024-03-15 11:04:11,117 DEBUG    root            Running [gcloud.auth.print-access-token] with arguments: []
2024-03-15 11:04:11,167 DEBUG    google.auth.transport.requests Making request: POST https://oauth2.googleapis.com/token
2024-03-15 11:04:11,174 DEBUG    urllib3.connectionpool Starting new HTTPS connection (1): oauth2.googleapis.com:443
2024-03-15 11:04:11,374 DEBUG    urllib3.connectionpool https://oauth2.googleapis.com:443 "POST /token HTTP/1.1" 400 None
2024-03-15 11:04:11,376 DEBUG    root            using google-auth reauth
2024-03-15 11:04:11,376 DEBUG    google.auth.transport.requests Making request: POST https://oauth2.googleapis.com/token
2024-03-15 11:04:11,470 DEBUG    urllib3.connectionpool https://oauth2.googleapis.com:443 "POST /token HTTP/1.1" 200 None
2024-03-15 11:04:11,472 DEBUG    google.auth.transport.requests Making request: POST https://reauth.googleapis.com/v2/sessions:start
2024-03-15 11:04:11,475 DEBUG    urllib3.connectionpool Starting new HTTPS connection (1): reauth.googleapis.com:443
2024-03-15 11:04:12,162 DEBUG    urllib3.connectionpool https://reauth.googleapis.com:443 "POST /v2/sessions:start HTTP/1.1" 200 None
2024-03-15 11:04:15,073 DEBUG    root
Traceback (most recent call last):
  File "/Users/redacted/google-cloud-sdk/lib/googlecloudsdk/core/credentials/google_auth_credentials.py", line 105, in refresh
    return self._Refresh(request)

here we go... IAM metrics for the SA.
fetch consumed_api
| metric 'serviceruntime.googleapis.com/api/request_count'
| filter
(resource.credential_id == 'serviceaccount:'
&& resource.method == 'google.pubsub.v1.Subscriber.StreamingPull'
&& resource.service == 'pubsub.googleapis.com')
| align rate()
| group_by
[resource.method, metric.response_code_class, metric.grpc_status_code],
[value_request_count_aggregate: aggregate(value.request_count)]

So in prod, are you doing anything to authenticate, or just using the default credentials for the cluster? (I suspect the latter - basically unless you've got a service account JSON file somewhere.) Will talk with Amanda about this. I think we may well be onto something. (It could be a red herring in the end of course.)
In terms of "what kind of credentials" there are three different types I can see at play here:

User credentials, when you authenticate as an individual - that's what I suspect you're using locally with gcloud auth application-default login
Service account credentials, as downloaded as a JSON file and either loaded explicitly or specified via the GOOGLE_APPLICATION_CREDENTIALS environment variable
"Compute" credentials, only available when running on GCP (including GKE) where the library talks to a metadata server and obtains a token that way

Then there's the matter of whether token exchange is involved or self-signed JWTs, but that's a second order.
To clarify this:

pull thinks it's working but it's actually failing silently forever.

I believe it actually knows it's failing, but just retries with exponential backoff (30s max) - but it retries forever rather than eventually failing, which is probably a mistake.
I've merged some logging - I'll chat with Amanda, but I suspect we'll be able to release a beta (or patch) tomorrow which will clarify things.

#12160 will publish version 3.10.1 - the only change is the addition of logging. The release should be complete and the package published in around an hour.
If you're able to test that version both locally and in GKE and collect any logs (you'll need to specify a Logger in the builder, of course) that would be really useful. It's far from impossible that it's an auth token refresh issue locally, but something entirely different in GKE - but the logs should tell us.

Try this log file. I started the debug session from zero. I remember something when I was first starting to debug with this test program: I started it, but it did not pull messages. I consulted a colleague. He reminded me to auth. Now I see exactly why it was failing - the lib keeps retrying auth without throwing. To me, it looks like it was running but inside it was silently failing over and over again.
In GKE, we create a K8s service account for each service. Then bind that to an IAM role. I'll see what I can do to get something running with Trace in one of our test envs and post some logs from that as well.
All done via Terraform.
resource "google_service_account_iam_binding"
...
role               = "roles/iam.workloadIdentityUser"
file2.txt

Firstly - thanks for jumping on this, that's really useful.
So yes, as we somewhat-expected, it's an auth error being surfaced as "internal" (I suspect due to the way gRPC wraps authentication). Internal errors are deemed retriable, so we try again.
It'll be really interesting to see if we get the same sort of pattern on GKE - it's unlikely to be the same auth issue, but if it's an auth issue that surfaces as an internal error, that would explain a lot. (And if something else is going wrong, hopefully the logs will show that instead.)

@Mihier-Roy: You may want to upgrade to 3.10.1 and specify a logger as well, to see if that helps to pin down the issue for you.

@jskeet I'm working on getting something running in a dev env to model the problem. We don't see a decline in open streaming pulls in our dev/test envs today - only in prod where the worker is busy around the same every day slogging through files that it pulls down from a bucket.
First pass at modeling this will be a Task.Delay that's controlled by a message attribute. No CPU, Memory pressure, Get object from bucket calls, or API calls between microservices in the GKE cluster, additional logging, etc that we would normally have.
I'll be out until next week so I won't have findings to post until then. Will ask a colleague to check up and post if anything interesting comes up in the meantime.

@philvmx1: Any updates with more logging?

Is there something in the OrderingKey algo that could cause streaming pulls to cease pulling as the number of OrderingKeys increases?

No, I wouldn't expect so - although I can't say I'm an expert on the precise details of all the options in Pub/Sub. I'm still hopeful that this was really due to the perpetual retry loop we can currently get into if auth fails with an error of "internal" (which we're still discussing internally, in terms of the best fix).

Any more information on this? I'm still hopeful that this is due to the perpetual retry on certain types of auth failure - which we're tracking internally.

It's been awhile, but I have new information regarding this issue. We put OrderingKey and OnlyOnce delivery on an existing pull subscriber. This is now causing the subscription to stop processing. As this one sees much higher volume of messages, this happens much more quickly. We're thinking it's related exceptions being bubbled up to StartAsync.
Documentation for StartAsync says exceptions are handled as if the reply was a NACK. We're going to try returning NACK explicitly instead of bubbling the exception to see if that resolves the issue for us.

Can you clarify exactly what you mean by "exceptions being bubbled up to StartAsync"? Do you mean that the subscriber task (returned by StartAsync) ends up being faulted? (Very similarly, when you say the subscription "stops processing" do you mean it just hangs like before, or that the task returned by StartAsync fails?)

Clarifications:

Yes, task is faulted.
It hangs like before.

stripped down version of code that describes the scenario:
// in our BackgroundService...

while(!stoppingToken.IsCancellationRequested)
{
        var subscriber = await GetSubscriber();
        await subscriber.StartAsync(async (msg, ct) => throw new Exception());

        await Task.Delay(1000, stoppingToken);
}

Sorry, I have a correction to make to the above comment - turns out we ARE returning NACK from our handler rather than rethrowing.
// in our BackgroundService...

while(!stoppingToken.IsCancellationRequested)
{
        var subscriber = await GetSubscriber();
        await subscriber.StartAsync(async (msg, ct) => SubscriberClient.Reply.Nack);

        await Task.Delay(1000, stoppingToken);
}

I'm confused - if the task is faulted, then it's not hanging like before - because before, the task didn't end up faulted, it just retried forever.
Are you saying that in some situation it's now faulting and in some other cases it's just retrying forever?
Note that if the task is faulted, your while loop would end up throwing.

Sorry, it's not faulting like I thought it was. Digging deeper into our own abstraction, we're catching, logging, and returning NACK in the Func passed to StartAsync.

Okay... rather than me trying to assemble a complete picture from the multiple comments, could you add a new comment with a reasonably full description of what you're observing? I think that'll be a better way forward. (Note that this will probably be my last comment for the day - I stopped actual work a couple of hours ago.)

To clarify/correct myself even further:
Our subscriber is hanging when we reply with NACK frequently when using message ordering and only once delivery. After 15 attempts with NACKs on each, these messages go to DLQ. There is a strong correlation with going to DLQ and halting pulls.

Able to repro!
set up program so it NACKs all messages.
create a topic.
create subscription with OrderingKey, max tries 5, and DLQ.
publish message with ordering key a1. It get pulled, NACK'd 5 times, goes to DLQ.
publish message with ordering key a2. It get pulled, NACK'd 5 times, goes to DLQ.
publish another message with ordering key a1... not pulled!
publish message with ordering key a3. It get pulled, NACK'd 5 times, goes to DLQ.
publish a message with any ordering key used previously...not pulled!

Right, I've managed to reproduce that. I'm going to try without the dead-lettering now, just to see if that's relevant. Once I've got a really minimal example, I'll create a PR with code that anyone can run.

https://github.com/googleapis/google-cloud-dotnet/pull/12961 is the repro.
Sample output:
2024-05-15T08:34:18.829Z info: Handler[0] Starting subscriber
2024-05-15T08:34:24.114Z info: Publish[0] Starting publishing.
2024-05-15T08:34:24.116Z info: Publish[0] Publishing message with text 'Normal 1' and ordering key 'normal'
2024-05-15T08:34:26.912Z info: Publish[0] Publishing message with text 'Normal 2' and ordering key 'normal'
2024-05-15T08:34:27.345Z info: Handler[0] Received message with ordering key 'normal' and text 'Normal 1'. Returning 'Ack'. MessageID='11153053032920147'
2024-05-15T08:34:29.013Z info: Publish[0] Publishing message with text 'Nack 1' and ordering key 'nack'
2024-05-15T08:34:29.461Z info: Handler[0] Received message with ordering key 'normal' and text 'Normal 2'. Returning 'Ack'. MessageID='11152815505479254'
2024-05-15T08:34:30.734Z info: Handler[0] Received message with ordering key 'nack' and text 'Nack 1'. Returning 'Nack'. MessageID='11152605002562264'
2024-05-15T08:34:33.236Z info: Handler[0] Received message with ordering key 'nack' and text 'Nack 1'. Returning 'Nack'. MessageID='11152605002562264'
2024-05-15T08:34:35.715Z info: Handler[0] Received message with ordering key 'nack' and text 'Nack 1'. Returning 'Nack'. MessageID='11152605002562264'
2024-05-15T08:34:38.254Z info: Handler[0] Received message with ordering key 'nack' and text 'Nack 1'. Returning 'Nack'. MessageID='11152605002562264'
2024-05-15T08:34:40.770Z info: Handler[0] Received message with ordering key 'nack' and text 'Nack 1'. Returning 'Nack'. MessageID='11152605002562264'
2024-05-15T08:34:44.260Z info: Publish[0] Publishing message with text 'Normal 3' and ordering key 'normal'
2024-05-15T08:34:44.360Z info: Publish[0] Publishing message with text 'Nack 2' and ordering key 'nack'
2024-05-15T08:34:44.446Z info: Publish[0] Publishing complete. Waiting for 2 minutes
2024-05-15T08:34:45.413Z info: Handler[0] Received message with ordering key 'normal' and text 'Normal 3'. Returning 'Ack'. MessageID='11152512446328396'
2024-05-15T08:35:25.458Z warn: Subscriber[0] Recoverable error in streaming pull; will retry. [...]

The last "recoverable error" part happens multiple times, but I don't think that's related to the issue. (I'll track that internally with a separate issue.)
The important part is that we don't get the "Nack 2" message.

(I won't be able to spend any more time on this today, but it's good that we've managed to reproduce it.)

Okay, having played with this a bit more and given the subscriber a bit longer, I see the following pattern:

Publish "nack 1" message
Message is received and nacked 5 times, ends up in DLQ
Wait for a bit (to make sure all the above has happened) - it gets confusing if the second message is sent while the first is still in the process of being nacked
Publish "nack 2" message (same ordering key)
The "nack 2" message is not received for some time, but it is received eventually

At which point it's nacked 5 times, ends up in DLQ

I usually see that the specific ordering key is "blocked" for about 2 minutes after the final nack - but I've seen longer and shorter times too. (And sometimes the gap between delivery attempts is on the order of a second - sometimes it's longer.)
While I haven't seen any documentation for this (and I'll ask the Pub/Sub team to confirm that this is the intended behavior and document it), I don't think the client is doing anything wrong here.
Now, this issue has gone through quite a few iterations - but does this description explain everything you're seeing?

We weren't seeing a recovery like you're seeing, even after days. But then again we several to hundreds of OrderingKeys rather than just 1.
What happens if you use more than one OrderingKey such as "nack1" "nack2" "nack3" ... and up to "nack6"? It seems to have made a difference when there are more than 4 or 5.

Thanks for the suggestion - I'll give that a go (although it might be on Monday).

NP.
IIRC, it stopped getting "ack" too after that.

IIRC, it stopped getting "ack" too after that.

Could you clarify precisely what you mean by that?

I mean that it stopped receiving messages entirely after messages with several OrderKeys went to DLQ within a short window (order of minutes perhaps). I didn't necessarily dig into this since I have some deadlines coming up very soon.
However, there was some very strange behaviors when sending a combination of "ack" and "nack" with different OrderingKey and some mixed in without an OrderingKey. I was basically doing exploratory testing at the time. We saw different things like the same message was handles again even though it was already ACK'd and things like that.
I would suggest sending OrderingKeys randomly chosen from a set of "ack1" - "ack6", "nack1" - "nack6", and "" (no ordering key).

Just tried with 10 ordering keys, and I got the same behavior as before:

Send 10 messages, each with a different ordering key
Nack them all (5x each)
Wait a bit
Send 10 messages, with the same set of 10 ordering keys as before
They all get received (after a while)

Will try with a mixture of acks and nacks (and no ordering key)... I'd rather not get into randomness though.

We've heard back from the Pub/Sub team, and they recommend that you open a support ticket via a Google Support ticket if possible - that will make it easier to provide details of specific topics etc confidentially, and the Pub/Sub team can look into specific instances. They're aware of some undesirable behavior in the backend when both Exactly-Once delivery and message ordering are enabled at the same time - a support ticket which involves the Pub/Sub team will make this easier to diagnose.

Will do exactly that! Thanks for your time and patience on this issue.

As of version 3.14.0, the "fail forever in the face of auth errors" issue has been fixed (in that now the subscriber will fail after there have been multiple auth-related errors separate to the RPC itself).

I ended here as I was tracking a sudden appearance of Unrecoverable error in streaming pull; aborting subscriber., from the changelog and this issue, I believe we updated past 3.14.0 and were hit by this. This might be a good thing - we've previously had issues where the pubsub client seemingly hangs for 10 minutes (seems like a timeout/retry) before continuing. We've lived with it thus far, but maybe this fixes that (or makes it apparent anyways).
Is there any guidance on how to create a client loop that restarts the client (ie. rebuilds & starts) and best practices here?
If I read the docs here, I see language like:

Registering the SubscriberClient doesn't automatically start the client. It needs to be started explicitly by calling the StartAsync method. The SubscriberClient is a long-running client and so it may be useful to use it in a background service. The background service can use the SubscriberClient registered with the dependency injection container and handle the messages in the background.

And:

Here SubscriberService is the class that implements BackgroundService and uses the SubscriberClient registered with the dependency injection container to handle the messages. Once the background service is registered, it will be automatically started when the application starts and stopped when the application exits. A sample implementation of SubscriberService is shown below:

In the sample service, the SubscriberClient is started once. But from reading this, StartAsync() will at some point stop when the internal retries hit their limit. This means my service will become nonfunctional (by default nothing keeps them alive or restarts them etc..)..
I'm moving ahead with a new BackgroundService that continually awaits StartAsync() and then has a small delay before building a new client and awaiting StartAsync again. This hopefully provides us with a form of recovery..

Is there any guidance on how to create a client loop that restarts the client (ie. rebuilds & starts) and best practices here?

Not really - because by the time the internal retries have hit their limits, we assume that there's something seriously wrong (which we cannot ascertain, otherwise we'd fix and retry).
Building a new client might help, but personally I'd be somewhat surprised - I suspect the kind of failure that leads to an unrecoverable error is more fundamental (e.g. a problem in the network connection itself).
If creating a new client does fix the problem, that would certainly be interesting information.

That was fast. We're deploying and testing the new version using the new library, and thus far (7 days) we've seen this issue three times. Every time we can restart our service (effectively building a new client) and happily trod on. In our production setup we haven't seen the same issue - the logs do not appear, and the symptom (no messages processed) doesn't appear. It's been running for months.
This is the log that the SubscriberClient logged using the logger we gave it. It's an aggregate exception that holds this information:
Grpc.Core.RpcException
   at Google.Cloud.PubSub.V1.SubscriberClientImpl.SingleChannel.HandlePullMessageData(Task`1 moveNextTask)
   at Google.Cloud.PubSub.V1.SubscriberClientImpl.SingleChannel.StartAsync()
   at Google.Cloud.PubSub.V1.Tasks.ForwardingAwaiter.GetResult()
   at Google.Cloud.PubSub.V1.Tasks.Extensions.<>c__DisplayClass4_0.<<ConfigureAwaitHideErrors>g__Inner|0>d.MoveNext()

As we're talking timeouts, we do set two settings on the client builder related to timeouts, and a few others. The whole setup is:
await new SubscriberClientBuilder
  {
	  Logger = Logger,
	  ChannelCredentials = _credentials.ToChannelCredentials(),
// GcpClientCount is 1
	  ClientCount = Options.GcpClientCount,
	  Settings = new SubscriberClient.Settings
	  {
		  // Consume batches of messages so we don't limit our consuming by our latency. This is an issue when we receive a lot of garbage, like GCS notifications for files we don't need to know about.
// GcpFlowControlCount is 100
		  FlowControlSettings = new FlowControlSettings(Options.GcpFlowControlCount, null)
	  },
	  ApiSettings = new SubscriberServiceApiSettings
	  {
// GcpStreamingTimeout is 5 minutes
		  StreamingPullSettings = CallSettings.FromExpiration(Expiration.FromTimeout(Options.GcpStreamingTimeout)),

// GcpAcknowledgeTimeout is 1 minute
		  AcknowledgeSettings = CallSettings.FromExpiration(Expiration.FromTimeout(Options.GcpAcknowledgeTimeout))
											.WithRetry(RetrySettings.FromExponentialBackoff(maxAttempts: 5,
												initialBackoff: TimeSpan.FromMilliseconds(100),
												maxBackoff: TimeSpan.FromMilliseconds(60000),
												backoffMultiplier: 1.3,
												retryFilter: RetrySettings.FilterForStatusCodes(StatusCode.Unavailable)))
	  },
	  SubscriptionName = _subscriptionName
  }

I'm not sure why we set the Pull Timeout, other than attempting to fix the issue I mentioned where we sometimes saw a delay of 10 minutes between messages being processed.

Right. Given how long this issue thread is, and that the hanging aspect has been fixed, could you create a new issue? Ideally with a minimal but complete project demonstrating the problem. It would be interesting to know if you still see the issue in a "totally vanilla" environment - using Application Default Credentials, default client count, default flow control settings, and default timing settings.

Will do if I manage to isolate this. I'll be logging on client aborts/stops so we can keep track of how often this happens. It might be that PubSub just has some issue that we now react to.
Is the guidance in the docs on "just use the long running SubscriberClient in your DI" still generally true? (start once, keep alive for the duration of the app).. If so, I'll investigate more on our end why it seems to not be working for us and get back.
Sorry for reviving the thread. Context just seemed important :)

Is the guidance in the docs on "just use the long running SubscriberClient in your DI" still generally true?

That's still the guidance I'd provide today, yes - until we can figure out why creating a new client is helping you. (That really does seem surprising, and I don't want to encourage other folks to use the "turn it off and on again" approach until we understand it better.)
It's worth noting that as of version 3.17.0, we're depending on Grpc.Net.Client 2.66.0 which has some changes around the HTTP version used. If you're not already on the latest (3.18.0) I'd definitely update to that - we've seen some odd (and hard to diagnose) issues around HTTP/3. I'm not saying it's related, but it's possible.


Release to prod-beta

:tada: This PR is included in version 1.11.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Visual Studio Docs

It would be nice to have the docs URL for Visual Studio to have an good old fashioned index page link so you can bypass all the marketing efforts to acquire new customers and get the current customer directly to the docs area where you can browse the categories/list and also search the topics.
Why flood the Docs home page with all the non-documentation links.
#SaveTheDocsHomePageBeforeItsTooLate

@ghogen

@tony-long Do you mean something like this:
https://docs.microsoft.com/en-us/visualstudio/windows/?view=vs-2019
If you scroll down past the Get Started section, you can see categories, etc.
If that's not what you were looking for, maybe you can expand on your suggestion.

Hi Gordon,   thank you for the follow-up.  Very sorry, but I forget what the request/case was that I suspect.   If I can offer some suggestions to the page link below –
On the tasks section -  a few more task names  that could be added:  Learn,   Demo – to get to use case based examples/demo and docs.
I would expect to see IoT in the work load area and good one would be “cross-device app design”
Thank you and stay safe.
<EMAIL_ADDRESS>From: Gordon<EMAIL_ADDRESS>Sent: Thursday, March 26, 2020 4:13 PM
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/feedback] Visual Studio Docs (#2486)
@tony-longhttps://github.com/tony-long Do you mean something like this:
https://docs.microsoft.com/en-us/visualstudio/windows/?view=vs-2019
If you scroll down past the Get Started section, you can see categories, etc.
If that's not what you were looking for, maybe you can expand on your suggestion.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/feedback/issues/2486#issuecomment-604733821, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB5IS3BVDT2A5CUQE7SO6RLRJPOSPANCNFSM4KSQ7JZQ.


Inherited fields are not serialized.

@see http://pastebin.com/RuXFsxD1 (Base class TestBean2.java)
@see http://pastebin.com/Yb2Hd1Zu (Derived class DerivedBean.java)
@see http://pastebin.com/EKuHNiTi (Unit test)
Unit test doesn't pass, because fields from TestBean2 base class are null. JDBM File doesn't contains inherited field definitions.

I used your fix, thanks


[Bug] Extension page opens up instead of bit.ly

Body
Opening the link http://bit.ly/WatchBrooklyn99Peacock Redirects to the extension page that says
"You aren't supposed to be here
Please open an issue on github to report this error.."
Extension version is 0.2334-Mv3 on Firefox, POP OS.
Version
Manifest-v3
What browser(s) are you seeing the problem on?
Firefox browsers
What platform are you seeing the problem on?
Computer (Windows, Linux, MacOS)
Anything else?
No response

Duplicate of #1190


Support for discriminator tag lookup in referenced schemas

What issue does this pull request resolve?
https://github.com/ajv-validator/ajv/issues/2261
What changes did you make?
Support for discriminator tag lookup in referenced schemas
Is there anything that requires more attention while reviewing?
no

Is this PR defunct? If you'd consider merging it with changes, I'd be open to contributing the changes back in. We would love to have it support discriminator in https://github.com/pactflow/swagger-mock-validator/issues/51.

@mefellows What changes would be necessary to get this merged? I'm happy to send another patch with those included.

I'm not a maintainer here, I'm just an interested party and are open helping out with direction from the project.

Whoops, my bad. I confused contributor of the pactflow repo with this one!
@epoberezkin would you be able to answer that question?

@josdejong any chance we could get this merged / looked at? it's been over a year and for openapi specs that use discriminator, mapping is almost required in most cases due to how ref can potentially be rewritten it's not as simple as plugging in the values to a static JSON Schema itself.

@epoberezkin  any chance we could get this merged / looked at? it's been over a year and for openapi specs that use discriminator, mapping is required in a lot of cases due to how ref can potentially be rewritten by Ajv it's not as simple as plugging in the values to a static JSON Schema itself.

@epoberezkin checking in as well, since we'd like to use swagger-mock-validator but mapping is an OpenAPI feature we use quite a bit. Could this be merged?
https://github.com/pactflow/swagger-mock-validator/issues/51


Opening Multiple windows on macOS: Not able to bring up the first window`

Setup
Open two different Oni2 windows. Use <cmd>+tab and try to bring the first window to the top.
Expected Results
<cmd>+tab should be able to be used to switch between the two windows.
Actual Results
Only the last opened window can be brought to the front using <cmd>+tab.  You have to hunt down the other window from the stack of window and click on it to ever see it. Or, close the Oni2 window that will come forward and then you can cycle around to the other one.
Not sure if this is related or not, but using alternate Docks causes the exact same behavior. Since I don’t ever use the macOS Dock, I’m not sure if it does or not. But, I’m sure it will behave in the same manner.
The uBar Dock replacement program has the same functionality, but causes a new window to be open every time it is used to bring up an existing window to the front. This is very annoying.
While the Keyboard Maestro “dock” (application list window) will only bring the last opened Oni2 window and never the first one. But, at least it doesn’t open a new window! ActiveDock behaves in a similar manner to Keyboard Maestro except only the first window opened is brought to the foreground.

Can you elaborate on how you are opening two Oni2 windows? On my Mac I'm not able to get multiple running to validate this.
-If I click on the app in my normal doc, I get one instance. I can't start another
-If I open one from my applications folder, and then a dev build, I get two separate instances running, and both are in my cmd+tab options.

The extra launching was due to a new Dock replacement. Not the normal Dock.
I sent him a notice about it.
But, When I have two instances of Oni2 running, I can only bring to the
front the last one. Both are viewable in the cmd+tab and dock, but only the
last one opened is brought to the front. The other one has to be manually
fronted by moving the other windows and clicking on it.
On Mon, Feb 24, 2020 at 8:07 AM Lee Matos<EMAIL_ADDRESS>wrote:

Can you elaborate on how you are opening two Oni2 windows? On my Mac I'm
not able to get multiple running to validate this.
-If I click on the app in my normal doc, I get one instance. I can't start
another
-If I open one from my applications folder, and then a dev build, I get
two separate instances running, and both are in my cmd+tab options.
[image: Screen Shot 2020-02-23 at 8 05 45 PM]
https://user-images.githubusercontent.com/359140/75123715-02b98b80-5678-11ea-82dd-9e94ea85b10b.png
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/onivim/oni2/issues/1268?email_source=notifications&email_token=AAS7JR376XDJJCKBF545XFDREMMTPA5CNFSM4KMCCQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWNAKQ#issuecomment-590139434,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAS7JR4O6UWAWQRIG3MS24DREMMTPANCNFSM4KMCCQGA
.

The current build of Oni2 allows me to switch between multiple instances of the Oni2 editor using cmd-tab just like I would expect. Thanks for that!
But, on the uBar and ActiveDock Dock replacement programs, clicking on the icon brings the application forward and launches a new copy of the application. On programs that are replacements for cmd-tab handle things correctly. I would assume it was a failure of the Dock replacement programs, but no other program I have (over 100) has this problem.

I think this is an issue with us specifying Oni2 as the executable in the Info.plist for Oni. We're working on migrating the executable to Oni2_editor for a separate issue, and I'll be curious to see if you have the same issues once that happens.
I'll keep you posted! Sorry you're having this issue!

@raguay I downloaded and tested the new builds with uBar and it seems to work as expected now. As for the multi-window/instance bug, since this isn't supported behavior as of now, I think we should close this issue for now. If you have another issue with the dock replacements, I would recommend opening a new issue since this one is only tangentially about that.
Thanks again!

Thanks. I'm traveling right now and can't test the new build. But, I will
put it through the works when I get home. It's the only editor I use right
now.
Thanks.
On Wed, Jun 3, 2020 at 7:46 AM Zach Baylin<EMAIL_ADDRESS>wrote:

@raguay https://github.com/raguay I downloaded and tested the new
builds with uBar and it seems to work as expected now. As for the
multi-window/instance bug, since this isn't supported behavior as of now, I
think we should close this issue for now. If you have another issue with
the dock replacements, I would recommend opening a new issue since this one
is only tangentially about that.
Thanks again!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/onivim/oni2/issues/1268#issuecomment-637888980, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAS7JRZPPKGSQ7MIZZY2LLDRUWMOFANCNFSM4KMCCQGA
.


Crate release automation

Tokio consists of many small, decoupled crates (a crate is a Rust library
package). Releasing changes has become a manual and error prone process. The
goal of the project is to build a set of tools to automate crate releases such
that the entire flow can be done via the GitHub issue tracker.
Expected outcomes

Changelog entries are generated based off of data in PRs including title and labels.
Crates are released on a weekly (configurable) basis.
A bot opens a PR for the release
When the release PR is merged, the crate is pushed to crates.io.
A Github status check is used to ensure that PRs include enough data to generate a changelog entry.
An automated GitHub action that merges master into PRs when there are no merge conflicts.

Skills

GitHub
TravisCI
Bash

Difficulty level
Easy

A large part of this will be continuing the shipit CLI tool: https://github.com/carllerche/shipit
Some design thoughts here: https://github.com/carllerche/shipit/pull/1


Integrate with the Dirtviz API (Due: 2024-02-23)

The serialization, LoRaWAN transmittion via The Things Network, and WiFi transmittion need to be implemented together for uploading to Dirtviz

This will be done as part of #25

Completed in #25


Applying custom theme

I am trying to apply a custom theme that I made (it is currently in a PR). The CSS file that I would like to use can be found  here.  I have tried using the following code with a URL to the CSS file (as suggested in the documentation) and have not succeeded in applying the desired color scheme to my comments section. When I try to apply the custom theme, all the colors in my giscus comments section go white.  I suspect I might be missing some rudimentary component and so any help is appreciated!
<script src="https://giscus.app/client.js"
        data-repo="sciarraseb/HugoWebsite"
        data-repo-id="R_kgDOIwrh4A"
        data-category="Comments"
        data-category-id="DIC_kwDOIwrh4M4CT1kX"
        data-mapping="pathname"
        data-strict="0"
        data-reactions-enabled="1"
        data-emit-metadata="0"
        data-input-position="top"
        data-theme="https://github.com/sciarraseb/giscus/blob/main/styles/themes/cobalt.css"
        data-lang="en"
        crossorigin="anonymous"
        async>
</script>

See https://github.com/giscus/giscus/discussions/877

Perfect! Thank you very much. I got it working by setting data-theme with JSDelivr's CDN. If any future users find this helpful, this is the structure to use for the data-theme entry:
https://cdn.jsdelivr.net/gh/<github-username>/<github-repo>@<commit-id>/<file-path>

where the file-path is relative to the root of the repository and commit-id is the commit ID for the file that needs to be served.
This results in the following entry for the data-theme field:
<EMAIL_ADDRESS>

Perfect! Thank you very much. I got it working by setting data-theme with JSDelivr's CDN. If any future users find this helpful, this is the structure to use for the data-theme entry:完善！谢谢。我通过使用 JSDelivr 的 CDN 进行设置 data-theme 来让它工作。如果任何未来的用户发现这有帮助，这是用于 data-theme 条目的结构：
https://cdn.jsdelivr.net/gh/<github-username>/<github-repo>@<commit-id>/<file-path>

where the file-path is relative to the root of the repository and commit-id is the commit ID for the file that needs to be served.其中 是相对于存储库的根目录， commit-id 是 file-path 需要提供的文件的提交 ID。
This results in the following entry for the data-theme field:这将导致该 data-theme 字段的以下条目：
<EMAIL_ADDRESS>

I tried so many ways to load my custom css url, but it always alert CORS at console. However, I use other bloggers' custom css url, it just works. I feel weird and upset. Fortunely, this way works. Thank you so much!


new: New landing page for docs

Describe this PR
revamp landing page for docs
https://www.notion.so/prismaio/Home-for-PDP-Docs-Q2-2023-d06bf035929b49d2850f1b24e55f262d
Design: https://www.figma.com/file/aTK3UuDkVlld0G1q0ik9fw/Docs-Website?type=design&node-id=1565-2815&mode=design&t=f1yceOEYsGPwbtIM-0
Changes

Update header/footer/index page
Add missing technology svgs

What issue does this fix?
Fixes #5089
Any other relevant information
Slack feedback thread: https://prisma-company.slack.com/archives/C5Z9TH6N9/p1690816036118739

Suggestions / feedback from https://prisma-company.slack.com/archives/C5Z9TH6N9/p1690816036118739

[ ] The github icon doesn't appear to be a link.
[ ] "cloud projects" and "classic projects" links seem broken
[ ] font jitter when the page loads
[ ] Prisma logo should link to prisma.io I think
[ ] "Docs" links to 404
[ ] The tiny house in the breadcrumb also links to 404
[ ] No page title
[ ] "Example projects" is an external link, but looks the same as internal one
[ ] Some links (towards bottom) are underlined
[ ] Kerning of "databases" buttons looks a bit off
[ ] https://pagespeed.web.dev/analysis/https-docs-git-new-docs-landing-page-prisma-vercel-app/5gsv4at8x0?form_factor=mobile + https://pagespeed.web.dev/analysis/https-docs-git-new-docs-landing-page-prisma-vercel-app/5gsv4at8x0?form_factor=desktop probably deserves a look
[ ] Quite a few 404s for fonts that don't exist: https://docs-git-new-docs-landing-page-prisma.vercel.app/docs/fonts/Inter-Regular.woff2
[ ] The "404" page does not seem to be centered
[ ] og:url is invalid for all pages
[ ] The left hand sidebar lost the "headline" (Get started, Concepts) etc - is that intentional?
[ ] Pages with long right-hand navigations now have a slightly different scrolling behavior: https://docs-git-new-docs-landing-page-prisma.vercel.app/reference/api-reference/prisma-client-reference vs. https://www.prisma.io/docs/reference/api-reference/prisma-client-reference
[ ] Less vertical content visible as the header always sticks around

"cloud projects" and "classic projects" links seem broken

@nikolasburk / @janpio Could you help me with the correct links here?

Some links (towards bottom) are underlined

@janpio This is according to design in https://www.figma.com/file/aTK3UuDkVlld0G1q0ik9fw/Docs-Website?type=design&node-id=1565-2815&mode=design&t=f1yceOEYsGPwbtIM-0

og:url is invalid for all pages

This issue happens only in previews - We have a blanket issue for fixing this across all the repos soon

Less vertical content visible as the header always sticks around

@janpio Looks like this is something according to agreed upon design interactions. Do you have any suggestions for this?

Some links (towards bottom) are underlined

@janpio This is according to design in figma.com/file/aTK3UuDkVlld0G1q0ik9fw/Docs-Website?type=design&node-id=1565-2815&mode=design&t=f1yceOEYsGPwbtIM-0

Ok, we should refine the design then to be consistent.

Less vertical content visible as the header always sticks around

@janpio Looks like this is something according to agreed upon design interactions. Do you have any suggestions for this?

Same here, I can give feedback that now less content is visible and that makes it harder to use the docs site and read its content. Potentially this design decision should be revisited.

More feedback:

[ ] bullet points are not visible in lists in safari, although they are in firefox
[ ] still have the flash of everything (it loads, then disappears for a few ms, and appears again).
[ ] "Planetscale" button should probably link to https://docs-git-new-docs-landing-page-prisma.vercel.app/guides/database/planetscale instead of prisma.io/planetscale
[ ] https://docs-git-new-docs-landing-page-prisma.vercel.app/concepts/components/prisma-client/working-with-prismaclient/generating-prisma-client vs. https://docs-git-new-docs-landing-page-prisma.vercel.app/concepts/components/prisma-client/working-with-prismaclient/connection-management - note how the content area shrinks in the second URL
Also happening for https://docs-git-new-docs-landing-page-prisma.vercel.app/concepts/components/prisma-client/full-text-search and https://docs-git-new-docs-landing-page-prisma.vercel.app/concepts/components/prisma-client/custom-validation)

Some links (towards bottom) are underlined

@janpio This is according to design in figma.com/file/aTK3UuDkVlld0G1q0ik9fw/Docs-Website?type=design&node-id=1565-2815&mode=design&t=f1yceOEYsGPwbtIM-0

Ok, we should refine the design then to be consistent.

Less vertical content visible as the header always sticks around

@janpio Looks like this is something according to agreed upon design interactions. Do you have any suggestions for this?

Same here, I can give feedback that now less content is visible and that makes it harder to use the docs site and read its content. Potentially this design decision should be revisited.

The navbar is the only element supposed to be sticky here, not the search bar! I've added a comment directly on the PR for this @janpio @nilubava

@nilubava I added a couple of comments on the PR directly.

[ ] All links should have underline as a hover state
[ ] Search bar in the homepage should NOT be sticky :)
[ ] The three lower cards at the end of the page now have no underline as default, to be consistent with the rest

[ ] Search bar in the mobile version is not displayed properly

@nilubava

[ ] all these also need underline when hovering

also @nilubava

[ ]  in some sections the breadcrumbs get cropped and the line height is minimal

[ ] Also these two drop-downs should go below the breadcrumbs

@nilubava

[ ] The search bar should NOT have a flat background beneath, but just a drop shadow, like in the Figma Prototype

@carlagn there still a page that does some funky-width things - all pages should have the same width
https://docs-git-new-docs-landing-page-prisma.vercel.app/reference/database-reference/database-features

Probably because of these tables, in the middle they have some funny spacing:

You can play with the max-width parameter and font-size too (I think other pages have a 668px width)

two more fixes;

[ ] can we make the Github logo in navbar open the link in new tab?
[ ] when clicking the 'Docs' text in nav bar, it goes to 404 instead of back to the Docs homepage?

@meletj

when clicking the 'Docs' text in nav bar, it goes to 404 instead of back to the Docs homepage?
This is because our previews do not have the /docs prefix. But prefixes work in production, as you can see the behaviour of the current '/docs' link in our navbar

@meletj

when clicking the 'Docs' text in nav bar, it goes to 404 instead of back to the Docs homepage?

This is because our previews do not have the /docs prefix. But prefixes work in production, as you can see the behaviour of the current '/docs' link in our navbar. We could test this by enabling the prefix for this branch

All good then