Publishing fails after seemingly random interval, requiring application restart

After a period of successful message publishing, all requests will begin timing out until the application is restarted. Interval has been observed to be anywhere from 1 to 7 days.
App is running within a container in GKE. It is a nodejs application built from a Typescript project using the following versions:
# nodejs --version
v14.21.3

# npm --version
6.14.18

# head -n4<EMAIL_ADDRESS>{
  "name": "@google-cloud/pubsub",
  "description": "Cloud Pub/Sub Client Library for Node.js",
  "version": "4.0.1",

There are 300 instances of our application running at all times, and each individual instance generates approximately 35 to 45 messages per second. The messages are split between three topics, the most heavily published topic receives up to approximately 35 messages per second per instance. Total message rate for all instances combined is between 11,000 and 13,000 messages per second.
Observed publication failures appear to impact only a single instance at random, and can occur half a dozen times or more throughout the day. It does not appear to be uptime-related, as some instances can run for a week before being impacted.
Once an application instance begins failing to publish messages, it fails all message publish requests until it is restarted.
Restart gets triggered by k8s due to memory consumption exceeding its maximum value. This can take 10 minutes or more as message publishing attemps back up and become queued.
The impact of a single application instance being in this state is that as many as 2,500 of our customers are unable to interact with their products until the instance they are communicating with is restarted. This is a significant degradation of service for these customers and is generating sizable support issues for us.
The errors reported by the Pub/Sub client all appear to indicate that the request has timed out.
"Error: Total timeout of API google.pubsub.v1.Publisher exceeded 60000 milliseconds before any response was received."
Other than this being observed on our production applications, I don't have a specific set of circumstances which can be used to reproduce it.
I have included the typescript source file, which is responsible for message publishing and error handling.
import {EventStreamPubSubConfig} from "../config";
import {eventStreamMetrics} from "../observability";
import {EventStream} from "./ievent_stream";
import {EventMessage} from "./event_message";

import * as bunyan from "bunyan";
import {PublishOptions, PubSub, Topic} from "@google-cloud/pubsub";

export interface EventStreamPubSubOptions {
    config: EventStreamPubSubConfig;
    log: bunyan;
    messageOrdering: boolean;
    topic: string;
    pubSub: PubSub;
}

export class EventStreamPubSub implements EventStream {
    private options: EventStreamPubSubOptions;
    private log: bunyan;
    private topic: Topic;

    constructor(options: EventStreamPubSubOptions) {
        this.options = options;
        this.log = options.log;
        this.topic = this.attachToTopic();
    }

    private attachToTopic(): Topic {
        const publishOptions: PublishOptions = {
            batching: {
                // We are intentionally processing 1 message at a time in queue::enqueue,
                // so we should tell the PubSub library to publish right away.
                maxMessages: 1
            },
            gaxOpts: {
                timeout: this.options.config.timeoutMillis
            },
            messageOrdering: this.options.messageOrdering,
        }

        if(this.options.config.retry.enabled) {
            publishOptions.gaxOpts!.retry = {
                backoffSettings: this.options.config.retry.backoffSettings
            }
        }

        this.log.info(`Creating publisher for topic ${this.options.topic} with options: ${JSON.stringify(publishOptions)}`)

        return this.options.pubSub.topic(this.options.topic, publishOptions);
    }

    async create(message: EventMessage): Promise<void> {
        const timer = eventStreamMetrics?.pubSubWriter.startTimer();
        let m = {
            data: Buffer.from(JSON.stringify(message.message)),
            orderingKey: message.orderingKey
        };
        return this.topic.publishMessage(m).then(
            (resp) => {
                this.log.trace("Publish successful: " + resp);
                timer?.({
                    result: "success",
                    topic: this.options.topic
                });
            },
            (reason) => {
                this.log.error("Publish failed: " + reason);
                timer?.({
                    result: "failure",
                    topic: this.options.topic
                });

                // Drop the current message and move on
                this.topic.resumePublishing(m.orderingKey);
            }
        );
    }
}

@nrheckman Can you try the latest version or try implementing the defaults from this PR?
https://github.com/googleapis/nodejs-pubsub/pull/1814
We've been seeing a bunch of these and have a belief that it may be fixed by enabling the grpc keepalives.

Looks like enabling GRPC keepalives fixed our problem!
Thank you!


Change layer name

This PR fixes #8246.

Also, it implements the deletion of the layer in the inner view:

cc @xavijam @piensaenpixel

Could we add, in this state, the modal confirmation for layer remove? please?

Ooooh!
Also, can we make double click on layer name to activate the editting box?

BTW this is ❤

Confirmation and double click done. But this last one is a bit tricky, at least in the layers list view, because we are adding click (to edit the layer) and double click (to edit the layer's name) event to the same element. I had to add some delay (250ms) to segment those actions.

Something I've done in the table with the rename is, create an '' with the table name, make it readonly and only enable it when we need to edit it. How does it sound?

Do we even have notifier events?

Of course.

vamosnenos

Done.

Ready then?


updates

have you guys come up with a solution to updating windows electron shell apps after they're installed?

Not yet... For now prio is to increase test coverage.
But we'll tackle this sooner or later.
Ideas or infos are more than welcome. :)

I've been working on this project for updates :smile:
https://www.npmjs.com/package/electron-updater

Nice!!!
@justinmchase So I think we can close this one and refer to your project, right?

You could. This project is new so it may not be perfect yet, but it seems to be complimentary to this one. I would appreciate any scrutiny and contributions are welcome.

Yeah let's do it like that. :)
Currently the updates are not prio, but I'd love to build up a family of electron-packager, electron-builder and electron-updater. :bowtie:

@justinmchase That's amazing, you're a lifesaver!  I'm going to use it and if I run into any issues I'll contribute them back.

@xcoderzach Take a look at the issues, there are a few features not yet implemented. If any of those are blocking you let me know.

@justinmchase @xcoderzach Great to see this going guys! :+1:


Out of Combat Move Speed Boost Fails to Function

The mod "Out of Combat Move Speed Boost" fails to work with Zombieland installed, i think this is because the map is constantly considered "in combat" for some reason relating to the zombies. OCMSB is one of my favorite mods and I would love to see this issue fixed (here's a log too encase that helps too)https://gist.github.com/b1c1e660d73ef1db5940591fb64ca019
-- submitted by<EMAIL_ADDRESS>

They hard code their functionality instead of reusing vanilla. Nothing to do here for me.


:bricks: walking skeleton

Why need this change? / Root cause:

So everyone can start develop.

Changes made:

Whole project

Test Scope / Change impact:

Whole project

Issue

resolved #19

artifactId 大寫看起來很不習慣 XD


VLC Player Needed

Yep, That need to be addressed in a way or another
Either remove python-vlc and make find a way to make library smooth when reading the next buffer
or emark small version of VLC.

The issue has been resolved with commit eaceb8bb91a0a0bfe3973a28ff5938592578a480.
Closes #1

The issue has been resolved with commit eaceb8bb91a0a0bfe3973a28ff5938592578a480.
Closes #1


Refactor build scripts for local and prod

Problem
Right now we only have a few build scripts, and they're all using Docker Compose. We need to restructure these into a format similar to the us_states module (potentially build_scripts/mi.sh as an example), and also allow for toggling the environment so that prod does not use Docker and local defaults to using sample data files rather than full.
Subtasks

[ ] Reorganize data loading shell scripts into a format similar to the Python module
[ ] Add an option for setting the environment for the build, and setting the files and use of Docker based on this
[ ] Document the process to make it easy for people to add additional build scripts

I can make a first pass at this in the next two days

I've been (slowly, busy time in the semester right now) working on automating the data pipeline, which I would see as complementing this pull issue. Basically, I want a framework + scripts that will obtain and transform whatever voter files (or other data) that are available online on a weekly basis.
The data loading shell scripts could also then be scheduled weekly, check to see if there is a file to load, load it if there is, and then delete the file loaded since there is a copy of the data in the DB. Alternatively, the files of cleaned data can also be kept as some sort of backup.

@JakeStevens that sounds great! Do you think splitting up the shell scripts this way will work with your ETL plan?
Want to make sure that this won't conflict with a more comprehensive ETL setup, but now that we're starting to load data this seems like a step in the right direction.

I think so. If there were shell scripts that I could call for data loading for each state/generic one that takes an input, then I can just call those scripts after obtaining new data

Thinking more about this, in theory loading the actual state data should be the exact same every time other than specific parameters (like report date and the filename).
The only thing that should be different between states is loading contextual information for things like electoral jurisdictions and precincts, which should theoretically be separate and only done on initial load. I'm not as familiar with those, so bringing in @BenGalewsky for context.
Should we just make build scripts the initial seed data on things like precincts and jurisdictions, and have one generic script for calling the state transformer on a file and then loading it with Pentaho?

Yes, I think we would need one generic script for calling the state transformer and loading a cleaned file into Pentaho. It would be nice to also have a script that only loads a transformed file into Pentaho; the scripts that I'm working on already fetches and transform state files, so I could use a script that only loads a transformed file


I don't understand apollo-module SSR behavior

Hello there !
When you go here AND then click on "blog" page (the first time ) https://yineo-website-rnuhrxdiwf.now.sh/contact
What i get :

Loading bar at the top go to 100% loaded, but posts are not yet loaded
My blogs posts are displaying "loading"
Blog posts appears once pulled by apollo from my GraphQL API server

What i expected :

Blog posts already rendered as html string by nodejs server
OR : loading bar do not go up until 100% if posts are not yet loaded

Am i doing something wrong here ?
Are posts actually Server Side rendered ?
See the corresponding code here :
https://github.com/nyl-auster/yineo-front/blob/fc0a4882f6565757552dff94352089db3b0e59ff/pages/blog/index.vue

@nyl-auster this might be related to https://github.com/nuxt-community/apollo-module/issues/16

Closing this issue for now. Please choose the solution suggested in #16 and use your own loading indicator.

There are still two questions i'm not sure about

What i expected :
Blog posts already rendered as html string by nodejs server

Are posts actually Server Side rendered ?

@nyl-auster if you are using prefetch statement of vue-apollo then your query will be handled on the server and thus the initial render will have the $apollo values present.
You will bump into server/client hydration error if the server and client differs. If not, then your code should have been rendered correctly

@dohomi yes you are right, i edited my first post : it is the normal behavior i guess that posts are loaded "on demand" when you came from another page. So the only issue is actually the loading indicator as you described it here https://github.com/nuxt-community/apollo-module/issues/16

@nyl-auster you need to wire up your own loading indicator because the official Nuxt loading depends on routing. If you have any more issues please open a separate issue.


Issue #74: Support phpstan/extension-installer

Fix #74
Because this is very useful :-)

:) thanks

Thanks !!!


would be nice to have a less backward idiomatic use of startWith

Because startWith is chained off of an observable, you end up having to write code that looks backwards from what's actually happening:
range(1,5).startWith(0);

It'd be nice to have some solution/alternative to chained startWith such that the thing you're starting off with, appears to the left of the observer it's supposed to precede, e.g. something like
Rx.Observable.startWith(0, range(1,5))

Yes, you could always write concat(just(0), range(1,5), but then what's the point of startWith other than to remove a just?
/cc @blesh

Sounds good to me. Should be pretty straightforward to implement with little to no impact on performance.

It is actually designed to be like that, because in practice you create a complex expression and then at the end you say startWith. That is just my 2 cents as the guy that designed startWith.

@headinthebox ... would you say it would be problematic to extend startWith to support this feature? Would you rather see a prepend type operator? like: myComplexObservable.prepend(someOtherObservable)
Or do you feel this isn't necessary?

I think it is not necessary; as I said, you usually only know at the very end of defining a long an complex someOtherObservable that you want it to start with a certain value.
The range example is not a very good convincing example, because if you want to start with 0 you start with 0 in the range.

I've been teaching startWith as if it would be "prepend" to people, and no one found it awkward.

@staltz @headinthebox
So we're clear, the proposed API change is just:  someObservable.startWith(1, 2, 3) would work as basically Observable.of(1, 2, 3).concat(someObservable)

Agree range isn't a convincing example, but in general it's very common for me to make an observable that fires now, and then is invalidated at some point in the future. It's useful for things with value semantics, among other use cases, and not so much when I'm building up something very complex but just need something to fire at the beginning.

Then you use concat (I do not understand at all what you mean by to make an observable that fires now, and then is invalidated at some point in the future)

@machty as @headinthebox said, isn't this behavior the concat operator? just(0).concat(range(1, 5))

@trxcllnt confirm.
At this point I guess I just wonder if startWith is worth the API bloat, but maybe that can't/shouldn't be changed at this point. Happy to have this issue closed.

I'm still not against this idea. I've not read a compelling argument not to add this feature. It would be a non-breaking change.

I guess if it greatly impacted performance, or severely broke some highly important tenet of Rx, I would be against it, but I see no evidence to that effect. It's not even adding a new operator, just enhancing an existing one.

Readability. startWith reads as "prepend", but "prepend" makes no sense in this case:
Rx.Observable.startWith(0, range(1,5))

Why not concat(0, range(1,5)) could detect if the argument is non observable and wrap it in a just Observable?

@staltz 'Rx.Observable.startWith(0, range(1,5))' wouldn't do anything.
I think the proposal was simply myObservable.startWith(value, value, value, value). It was just to allow more than one value. It wouldn't break the API, I don't think it's unreadable. My only concern would be effects on the performance of startWith.
My counter-proposal was myObservable.prepend(Observable.of(value, value, value, value)) where prepend is really just a specialization of concat.
Of the two I can see the value of either. However I think the latter has a higher value proposition, because it's more flexible. The only problem being is I'm relatively adverse to operator bloat.

:-1: to prepend.
That example could have been pretty readable as
Observable.of(value, value, value).concat(myObservable)
I'm indifferent to startWith with multiple parameters, although I can't see it being that useful, and we don't have anyone in this thread actively advocating it, so I wouldn't add it.

I'm neither inclined to agree or disagree.
I'm not a fan of adding unnecessary operators though. So yes, :-1: to prepend. concat is fine for that case.
Also, you can always do:  Observable.of(3, 4, 5).startWith(2).startWith(1)
Re-closing I guess.

I'm going to just reclose. There doesn't seem to be a lot of interest in a static startWith, a multiparam startWith or a prepend.


Implement new runtime stream value

Fixed with https://github.com/ballerina-platform/ballerina-lang/pull/20735 ...


[DM-32811] Convert to FastAPI and kubernetes_asyncio

Convert Moneypenny to FastAPI from aiohttp.  Use Pydantic for input
validation instead of a JSON schema.  Update some boilerplate to
the standard FastAPI template.
Convert the Kubernetes layer to kubernetes_asyncio so that it won't
block other operations while Kubernetes operations are in progress.
Use FastAPI BackgroundTasks instead of aiojobs to kick off the
creation and management of the Kubernetes pod that does the work.
Use a workaround from StackOverflow to inject those tasks into the
main asyncio loop rather than running them as normal background tasks
to work around a limitation in use of httpx for testing.
Mock Kubernetes for testing, allowing the full test suite to be run
without a Kubernetes cluster.

Tested on data-dev where it seems to work well.


Fix breaking logic in request.slot()

I started receiving the following Intent Requests when an empty slot is provided:
{
    "type": "IntentRequest",
    "requestId": "amzn1.echo-api.request.ID",
    "timestamp": "2018-02-10T18:35:41Z",
    "locale": "en-US",
    "intent": {
        "name": "PersonIntent",
        "confirmationStatus": "NONE",
        "slots": {
            "Name": {
                "name": "Name",
                "confirmationStatus": "NONE"
            }
        }
    }
}

This was causing my function request.slot(SlotName, defaultValue) to fail. Because as it stands the logic in request.slot() doesn't check if the value is 'undefined' and so doesn't return the 'defaultValue'. This fixes that.

Thanks. This needs tests and changelog, please.

will update soon 👍

@dblock Updates made. All but 1 tests pass due to a dslint error in types/index.d.ts which I did not modify. Would look into it more  if you want me to.

@dblock there's some problem with dtslint's strict-export-declare-modifiers rule (ref 1, ref 2).
Maybe it's worth disabling for now? (it affects other builds as well)

Good news / bad news: on a hunch, I had Travis re-build master, and it's now red.
The problem is we're pointing dtslint at its production branch, as per https://github.com/Microsoft/dtslint/issues/71.

Yeah, doing some IT work on our dtslint config cleaned that up (albeit in the form of ignoring the error, rather than switching versions). See #316.
@User1m want to rebase off of that branch?

Thanks @lazerwalker  for the fix 👍
@dblock we're all green. Would love for a merge soon.
Thanks guys

Merged, thanks for hanging in here with my OCD!


Unable to create ADF Azure Storage Linked Services

Library name and version
Azure.ResourceManager.DataFactory 1.0.0-beta.2
Query/Question
While trying to create an ADF resource with linked services, pipelines, etc, the creation of the Linked Service happens "successfully" however, the resource is not in a usable state.
Snippet:
private async Task<FactoryDatasetResource> CreateBlobDataset(
        DataFactoryResource adf,
        StorageBackupConfigEntry entry)
    {
        var prodResourceGroup = await this._azure.Production.GetResourceGroupAsync(entry.ResourceGroup);
        var storage = await prodResourceGroup.Value.GetStorageAccounts().GetAsync(entry.AccountName);

        StorageAccountKey key = default!;
        await foreach (var k in storage.Value.GetKeysAsync()) // Yeah this is ugly, but is what we have in the API...
        {
            key = k;
            break;
        }

        var blobLinkedService = new AzureBlobStorageLinkedService()
        {
            ConnectionString = BinaryData.FromObjectAsJson($"DefaultEndpointsProtocol=https;AccountName={entry.AccountName};AccountKey={key};EndpointSuffix=core.windows.net;"),
        };

        var data = new FactoryLinkedServiceData(blobLinkedService);

        var linkedService = await adf.GetFactoryLinkedServices().CreateOrUpdateAsync(WaitUntil.Completed, entry.AccountName, data);

        var linkedServiceReference = new FactoryLinkedServiceReference(FactoryLinkedServiceReferenceType.LinkedServiceReference, linkedService.Value.Data.Name);

        var blobDataSet = new BinaryDataset(linkedServiceReference);

        blobDataSet.Parameters.Add("container", new EntityParameterSpecification(EntityParameterType.String));

        blobDataSet.Parameters.Add("directory", new EntityParameterSpecification(EntityParameterType.String));

        blobDataSet.DataLocation = new AzureBlobStorageLocation()
        {
             // Couldn't find the proper class to represent the expression so, using anonymous type
            Container = BinaryData.FromObjectAsJson(new { value = "@dataset().container", type = "Expression" }),
            FolderPath = BinaryData.FromObjectAsJson(new { value = "@dataset().directory", type = "Expression" })
        };

        var ds = new FactoryDatasetData(blobDataSet);

        var blobDs = await adf.GetFactoryDatasets().CreateOrUpdateAsync(WaitUntil.Completed, entry.AccountName, ds);

        return blobDs.Value;
    }

When opening the Linked Service resource in the ADF designer, I see the resource there without any errors. But when I click on it and try to Test the connection (or if I try to run a pipeline that uses it) I get the following error:
Invalid storage connection string provided to 'UnknownLocation'. Check the storage connection string in configuration.
 No valid combination of account information found.
 Activity ID: e49844bf-4d63-4d76-a9fb-65a69127aa53.

I would appreciate any light on what may be missing here.
Thanks!
Environment
.NET SDK:
 Version:   7.0.102
 Commit:    4bbdd14480

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.3
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/7.0.102/

Host:
  Version:      7.0.2
  Architecture: arm64
  Commit:       d037e070eb

.NET SDKs installed:
  6.0.405 [/usr/local/share/dotnet/sdk]
  7.0.102 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

@galvesribeiro Thank you for your feedback.
Consider asking the service staff for confirmation as this can be a service behavior.

I found the problem.
var blobLinkedService = new AzureBlobStorageLinkedService()
        {
            ConnectionString = BinaryData.FromObjectAsJson($"DefaultEndpointsProtocol=https;AccountName={entry.AccountName};AccountKey={key};EndpointSuffix=core.windows.net;"),
        };

This was using .ToString() while it should be using key.Value.
Sorry for the confusion and thanks for the replies.


feat(linter): add oxc-security/api-keys

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#5906  👈
#5905
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @DonIsaac and the rest of your teammates on  Graphite


fix(notifications): handle slack errors silently

Right now, Slack exceptions prevent submission of tasks, but we shouldn't be breaking on notifications in most cases.
NOTE: We might not want to ignore slack errors all the time? For example, if we're trying to add someone to a Slack group from the project management view we probably want to surface that error.

Coverage decreased (-0.1%) to 91.544% when pulling 30183a9ab501d0f3b1f4a6491c84c266f92c0070 on slack-errors into 6b4348db4252b7e770b90e13ef9ff1cc6432abed on master.


[v3.2] dts: vendor-prefixes: deprecate facebook and add meta

Backport of #61351 for v3.2-branch.
Fixes #61337
Fixes #61380

hey @cfriedt, 3.2 is unsupported, don't think we should backport that far

@fabiobaltieri - I think we might have had some teams using that branch internally.. but ... trying very much to upstream / reduce forking internally and this is (maybe surprisingly) the easiest way to at least set a good example to ensure things are consistent.
I'm fine with this is dropped, but @henrikbrixandersen reminded me that I had broken backports to update.
CC @DaWei8823

I see your point but unless it's really an major obstacle for you I'd rather close this and not push anything on unsupported releases. This in particular is not a big deal, but then we'd end up merging on old release branches forever. I think at that point you should really keep your fork if you are based on a way out of date release.

Not entirely sure why this even needs to be backported (to any branch)? I mean, we usually do not backport deprecations - and we support out-of-tree lists of vendor prefixes.

Not entirely sure why this even needs to be backported (to any branch)?

Well, it's because facebook legally changed it's name a while ago, we have internal forks of Zephyr, and several teams will need a coherent migration strategy.

I mean, we usually do not backport deprecations

Yea. I'm not actually sure why facebook was added here in the first place without having an in-tree driver of some kind, but it's there, and we should try not to break out of tree users. I think we have a few drivers that could be submitted upstream before LTS.

and we support out-of-tree lists of vendor prefixes.

As I mentioned already, doing it in-tree is (maybe surprisingly) the easiest way for me to ensure that it is consistent.

I agree with @dkalowsk


QA & Cert: RATA 16 (Reference Method Code Valid)

The scope of this ticket is to address the following RATA Summary DTO Checks
QA and Certification Data Checks

[x] RATA-16 - Reference Method Code Valid (Results C, D and E)

RATA-16 Works as expected


Install script broken after 2.20.6 release

Operating system
Ubuntu 22.04.2
Kluctl Version
2.20.6
Kubernetes Version
n/a
kubectl Version
n/a
Bug description
Running the install script curl -s https://kluctl.io/install.sh | bash no longer works after the latest release.
Steps to reproduce
Run fresh install using curl -s https://kluctl.io/install.sh | bash
Relevant log output
[INFO]  Downloading metadata https://api.github.com/repos/kluctl/kluctl/releases/latest
[INFO]  Using 2.20.6 as release
[INFO]  Downloading hash https://github.com/kluctl/kluctl/releases/download/v2.20.6/kluctl_v2.20.6_checksums.txt
[INFO]  Downloading binary https://github.com/kluctl/kluctl/releases/download/v2.20.6/kluctl_v2.20.6_linux_amd64.tar.gz
[INFO]  Verifying binary download
[INFO]  Installing kluctl to /usr/local/bin/kluctl
mv: cannot stat '/tmp/kluctl-install.KwlbaYeyqD/kluctl': No such file or directory

Using { echo kluctl_VERSION=2.20.4; curl -s https://kluctl.io/install.sh; } | bash as a temporary solution

Thanks for reporting this. #630 contains a fix which will be included in v2.20.7, which I'll probably release tomorrow.

Thanks!


Get HF Username in Session

Need a way to get the Huggingface Username of the user in main.py, this could be a way to authenticate the user.
Gradio seems to support this (check: https://github.com/gradio-app/gradio/pull/4943, and https://huggingface.co/spaces/Wauplin/gradio-oauth-test). Need to extend this to Chainlit.

Not relevant anymore since we're using Google OAuth


Fix PSSA Issues in AntiMalwareScanning (Fixes #61)

Fixing the PSSA Issues in MSFT_xExchAntiMalwareScanning.
Running Invoke-ScriptAnalyzer with the following rules excluded no longer has any output:
PSUseShouldProcessForStateChangingFunctions
PSDSCDscTestsPresent
PSDSCDscExamplesPresent
These rules have been approved to be ignored.

This change is

Hi @kwirkykat, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Katie Keim). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Pilosa locks up during import with buffer-size set to 1

Expected behavior
Import runs (probably pretty slowly), but everything works.
Actual behavior
Running the (soon to be released) pi bench import-zipf with buffer-size=1 can cause a single node Pilosa to enter a strange deadlocked state after about 4000 bits.
Steps to reproduce the behavior
The client-go-pilosa branch in the tools repo (not yet open source) has the client code which can reproduce this. Run pilosa locally with default args, and then run pi bench import-zipf --buffer-size=1 - you should get an EOF error, and Pilosa will no longer respond to requests. (If you get the error and Pilosa continues being able to serve requests, running the import again should stop it - that's what I've seen anyway).
Information about your environment (OS/architecture, CPU, RAM, cluster/solo, configuration, etc.)
Macbook Pro

The source of the crash is pilosa is running out of file handles.  I see two parts to completely solving this issue, enhancing pilosa to protect against too many connections (#760) and modifying the client to handle multiple requests more efficiently and improved cleanup.


Plugin crashed when performing Bulk prompt import using version 1.49.2 and 1.48.3.

Tried to import more than 130 prompts to an Org and the plugin crashed halfway. Please look in to it.
Workaround: Imported 40 prompts files at a time to overcome this problem.
Analysis: In each run, initial 25 to 30 prompts get created not exceeding 2 to 5 sec of elapse time. After that noticed prompts started taking more time to get created and if the upload takes more than 50 sec, then the plugin crashes.

Log:
│ Error: Plugin did not respond
│
│   with genesyscloud_architect_user_prompt.xxxx,
│   on main.tf line 1411, in resource "genesyscloud_architect_user_prompt" "xxx":
│ 1411: resource "genesyscloud_architect_user_prompt" "xxx" {
│
│ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ValidateResourceConfig call. The plugin logs may contain more details.
╵
Stack trace from the terraform-provider-genesyscloud_v1.48.3.exe plugin:
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x20 pc=0x1ada90a]
goroutine 4594 [running]:
terraform-provider-genesyscloud/genesyscloud/architect_user_prompt.(*architectUserPromptProxy).verifyPromptResourceFilesAreTranscoded.func1()
terraform-provider-genesyscloud/genesyscloud/architect_user_prompt/genesyscloud_architect_user_prompt_proxy.go:275 +0x14a
github.com/hashicorp/terraform-plugin-sdk/v2/helper/retry.RetryContext.func1()
github.com/hashicorp/terraform-plugin-sdk/v2@v2.34.0/helper/retry/wait.go:30 +0x4e
github.com/hashicorp/terraform-plugin-sdk/v2/helper/retry.(*StateChangeConf).WaitForStateContext.func1()
github.com/hashicorp/terraform-plugin-sdk/v2@v2.34.0/helper/retry/state.go:113 +0x1b0
created by github.com/hashicorp/terraform-plugin-sdk/v2/helper/retry.(*StateChangeConf).WaitForStateContext in goroutine 4372
github.com/hashicorp/terraform-plugin-sdk/v2@v2.34.0/helper/retry/state.go:86 +0x23b
Error: The terraform-provider-genesyscloud_v1.48.3.exe plugin crashed!
This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

Hi @ramukhsihtas7. We'll get an engineer working on it as soon as we can.
It looks like the reason that the plugin is crashing is because there is an error that is not being returned (line 275 of this file). If you call the endpoint GET /api/v2/architect/prompts/{promptId}, you should see the error that is causing this crash and maybe you can work around it until we get a fix out on the next release.
It is possible that the API call is failing because the oauth client you're using does not have the required permissions (architect:userPrompt:view) for the endpoint.
Thanks for reporting
-Charlie
(Tracking with DEVTOOLING-882)


Feature/autogenstudio UI extra headers

Why are these changes needed?
Problem: The autogenstudio library lacked the ability to specify default headers for API requests. This caused issues when APIs required specific headers to be included in every request.
Solution: I've extended autogenstudio to accept an optional default_headers parameter. This parameter allows developers to define a dictionary containing the desired headers, which will be automatically included in all API requests generated by autogenstudio.
For example, when any custom API needed some extra headers to complete the request:
"default_headers": {"X-Requester-Token": "<requester_token>"}
The llm_config parameter already accepts this configuration, but it wasn't possible to pass it via the autogenstudio via model creation.
Checks

[x] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[x] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[x] I've made sure all auto checks have passed.

Extra info
This MR was done originally in here, but it was needed to create this in the upstream repo for openai tests to run.

@ronaldpereira ,
Thanks, this looks like a valuable PR enabling the ability to add default_headers.
Two things:

it seems that you have made changes to client.py. I would separate that into a separate PR to effectively discuss that change since it is beyond the scope of autogenstudio
we are finalizing a PR that improves the database for autogenstudio which will likely conflict with the changes you have made here to datamodel.py and dbutils.py. I'd love to work with you to integrate default_headers in that PR. https://github.com/microsoft/autogen/pull/2425

Thanks for the review, @victordibia !

it seems that you have made changes to client.py. I would separate that into a separate PR to effectively discuss that change since it is beyond the scope of autogenstudio

Hmm, I usually don't like to split a single MR feature into two different MRs because it can result to code being broken. I like to view this MR as a frontend+backend unity, as if I merge the frontend first, it can break the model creation in studio unwillingly.

we are finalizing a PR that improves the database for autogenstudio which will likely conflict with the changes you have made here to datamodel.py and dbutils.py. I'd like to work with you to integrate default_headers in that PR. Rewrite AutoGen Studio Database Layer to Use SQLModel ORM #2425

I thinking of a better approach to this: I can point this MR to your MR and keep updating and solving merge conflicts that will eventually show. Then when your MR is in the ready state, we can merge this MR into it and then merge all of them into the main branch. Do you think it's a better idea?
I can still split this into two different MRs and create a merge dependency for the backend in the frontend part if you wish, no problem.

Codecov Report
Attention: Patch coverage is 50.00000% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 28.56%. Comparing base (372ac1e) to head (36483a7).
Report is 29 commits behind head on main.

Files
Patch %
Lines

autogen/oai/client.py
50.00%
1 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2433      +/-   ##
==========================================
- Coverage   33.11%   28.56%   -4.55%
==========================================
  Files          86       87       +1
  Lines        9108     9340     +232
  Branches     1938     2140     +202
==========================================
- Hits         3016     2668     -348
- Misses       5837     6358     +521
- Partials      255      314      +59

Flag
Coverage Δ

unittest
12.70% <25.00%> (?)

unittests
27.79% <50.00%> (-5.32%)
:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

This PR is against AutoGen 0.2. AutoGen 0.2 has been moved to the 0.2 branch. Please rebase your PR on the 0.2 branch or update it to work with the new AutoGen 0.4 that is now in main.

Hi @ronaldpereira - we rebased this for you but it looks like there are still some conflicts. If you are still interested in bringing this forward please have a look at resolving the conflicts and greening the CI

Hello @rysweet,
The recent changes to the autogen studio have affected the database and UI design I've implemented, so adjustments will be needed to make this mergeable. I believe it would be more efficient to create a new branch from scratch using the current codebase, rather than trying to adapt the existing one in this MR.
Therefore, I'll close this MR for now and will open a new one, referencing this, once the new branch is ready.
Thank you for rebasing this MR for me.


[Fill component] Size range values doesn't trigger changes

Fixed in wizards-part1: https://github.com/CartoDB/cartodb/commit/531e96eb284024071ff94f9412164006209e1aa7

\o/


Adding docs

Updated UG with product description and revert appendix section

Codecov Report
Base: 76.04% // Head: 76.04% // No change to project coverage :thumbsup:

Coverage data is based on head (bff1e3c) compared to base (cd31eeb).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #243   +/-   ##
=========================================
  Coverage     76.04%   76.04%
  Complexity      685      685
=========================================
  Files           100      100
  Lines          2025     2025
  Branches        226      226
=========================================
  Hits           1540     1540
  Misses          406      406
  Partials         79       79

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

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


[tlul/rtl] Change ASSERT_I to ASSERT to fix erroneous assertion failure

ASSERT_I is not disabled during reset or when reset is unknown, so it fails erroneously.  This caused a large number of tests (32 according to the current report) in Darjeelings xbar_main regressions to fail.
This commit fixes that problem by changing the assertion to ASSERT, which is disabled when reset is not deasserted (thus it's also disabled when reset is unknown).
This is a cherry-picked commit from https://github.com/lowRISC/opentitan/pull/20571, as requested in this comment.

CHANGE AUTHORIZED: hw/ip/tlul/rtl/tlul_socket_1n.sv

CHANGE AUTHORIZED: hw/ip/tlul/rtl/tlul_socket_1n.sv


IPAddressClaim controller should detect cluster paused consistently

Changes were recently made to the IPAddressClaim controller to prevent reconciliation when the Cluster object is paused. The Cluster object has a spec.Paused property, and can also have a Paused annotation. The code copied from CAPV and placed into the IPAddressClaim controller looks at the Cluster's spec.Paused property during updates, and looks at the Cluster's paused annotations during creates. It seems the Update and Create functions should both look at both the annotation and the property.
https://github.com/telekom/cluster-api-ipam-provider-in-cluster/blob/main/internal/controllers/ipaddressclaim.go#L76-L88
We thought this was odd and @srm09 agreed. We opened this issue on CAPV as a result of our discussion.
https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/issues/1890
Sagar suggests this paused detection predicate should be a shared library function owned by either CAPV or CAPI, and all controllers should detect paused in the same. This issue is a reminder to update the IPAddressClaim controller when the CAPV issue is resolved.

Yes, we should use annotations.IsPaused() instead of annotations.HasPaused().


Joken JWKS version 2.0

This library is around 5 years old currently and not only my understanding of the environment and language has hopefully evolved but also the uses of JWKS and the understanding of the spec itself is better nowadays. So, I think it is time we discuss a bit about a 2.0 version.
Current breaking issues are:

We should support kid-less and duplicated kids in sets as per the discussion on #37
We are simply using process the wrong way and have caused unfortunate side-effects #40
More and more people want to use a fixed set of JWKs sources and even a completely dynamic set of sources #39
Manually re-fetching might help solve some issues to some people during emergencies #30

These have to be tackled either way (breaking or not).
Some others I think are important:

JWKS claims like certificate thumbprints are increasingly important for security

This has mainly x5t and x5c claims as targets

Better HTTP configuration would also have helped avoid needing to release new versions
More observability would also help here (not only HTTP events per-se but also cache events for example)
Better guides and documentation examples (many issues were open about that in the past)
More options to re-trigger fetching (like cache expiration as mentioned on #35

I will have time to work on these on May. If anybody has any other issues that would like to see added here please join the discussion :)

We are about a year past this... unfortunately a few things happened that pushed me away a bit from the OSS work... changed jobs, lived abroad for a while, currently working with a different stack... in the meantime also a sad thing happened. I had a working version of a pure Elixir JWT library that I stupidly lost in a switch of machines...
So, all in all, just wanted to let people know that I am slowly regaining time to rework my way through these discussions and will re-code a pure Elixir version of a JWT library... it will take time but key validation through x509 will be built-in (with an additional optional dep of x509 of course...).
After that I hope to come back to a 2.0 version of jwks. In the meantime I will probably release a new version with the new process structure currently in master.
For anyone watching this issue, thanks for your patience! OSS is rewarding in many ways but I can't live off of it for now so I have to do with the little spare time here (but I plan on becoming a linux kernel developer for retirement... that is still some decades away hopefully... ).
I am still looking at all issues and if any nasty one appears I try to make some room to help and not let this get stuck.


Clearing all cells while scrolled down messes with vertical scrolling

Testing #114969
Repro:

Open a notebook
Scroll down all the way
Clear all cells
Start scrolling up, it looks like webviews able to scroll position are only removed when you scroll up or something?

already fixed and no longer reproduced in latest build.


Restructure getting started

This PR:

Separates local and kubernetes setups
Moves Redis setup to Kubernetes section
Creates separate steps for Hello World in Getting Started index

https://github.com/dapr/docs/issues/914

Thanks Yaron! I took your changes and split out the CLI into its own doc as well and updated the rc1 docs. Website coming soon. I think it will be easier to merge from website back into master so I'll close this PR and create the new one.


Changing settings doesn't alter Github webhooks

Changing repository settings doesn't alter Github webhooks. For example, we want to disable pull requests from triggering Drone builds but unchecking that checkbox doesn't change Github webhook settings.

This is the expected behavior.  These flags in the user interface are used to filter incoming webhooks. They are not meant to interact with or modify the github webhooks.
We have a discourse forum you can use if you have any further questions. Thanks
https://discourse.drone.io/


fix timezone

Hey,
Can you articulate in this ticket both what the original and new behavior is and/or make that clear in the code signature?

@ctsims I wanted to wait until I had more information from that ticket to confirm I'm actually solving the correct problem, but the problem is best described in the SO in the code:
http://stackoverflow.com/questions/5451152/how-to-handle-jodatime-illegal-instant-due-to-time-zone-offset-transition/5451245#5451245
Essentially, we're trying to convert a moment in time that does not exist to UTC. The common example is let's say country Foo goes to daylight savings time  at 2am so that at 1:59:59 on March 31 we immediately jump to 3:00:00. Then if we try to use time 2:00:00 Mar 31 in this timezone, that time does not exist and so cannot be converted to a UTC time.
We resolve this by getting the timezone offset for the device' time zone and applying this to the date time we create from the picker (which otherwise just takes some default time value as we cast the Date to a DateTime)

Fixed in https://github.com/dimagi/commcare-odk/pull/602


Github Pull Requests and Issues Extension Bug

Does this issue occur when all extensions are disabled?: Yes/No  no

here's what the report issue thing gave me:

Issue Type: Bug

I've been trying to sign in with Github in VSC, but everytime i do it, it says error signing in to github every time. Once i press try again, it just asks for permission to sign in and after a while, the error pops up.

Extension version: 0.37.2022030309
VS Code version: Code 1.65.0 (b5205cc8eb4fbaa726835538cd82372cc0222d43, 2022-03-02T11:12:08.962Z)
OS version: Windows_NT x64 10.0.17763
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Celeron(R) N4000 CPU @ 1.10GHz (2 x 1094)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: disabled_offoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
1.83GB (0.38GB free)

Process Argv
--open-url --crash-reporter-id 19f94b53-0004-433f-a859-473dfe3a5dd3 -- vscode:extension/GitHub.vscode-pull-request-github

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30433507
vsclayoutctrt:30448491
vsrem710cf:30416617
dsvsc009:30440023
pythonvsnew555:30442236
vsbas813:30436447
vscscmwlcmc:30438804
vscgsvidc:30447482
helix:30440343

VS Code Version: should be in the issue reporter thing
OS Version: should be in the issue reporter thing

Steps to Reproduce:
1.try to sign in with the github pull requests and issues and allow it to sign in
2. error pops up

Note: I just tried again and saw this error message:

Error loading webview: Error: Could not register service workers: InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state..

@TylerLeonhardt, could you please take a look as this seems to be related to the GitHub auth flow. Thanks!

/gifPlease

I've noticed a similar issue with 1.65.2 and Github Pull Requests v0.38.1. At first Github auth seems to be successful but shortly after the prompt reappears. Looking through the logs I believe the extension can't handle API rate limit errors and thus thinks auth wasn't successful.
/CC: @alexr00
[Info] Found GitHub remote
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] Review> no matching pull request metadata found on GitHub for current branch dev
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues with query: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .
[Info] GithubRepository> Unable to fetch issues without milestone: Error: GraphQL error: API rate limit exceeded for user ID ... .

GitHub Pull Requests and Issues shouldn't hit the API rate limit at all when the user is signed in. @TylerLeonhardt do you know if it's possible to hit the API rate limit when signed in?

Not sure how, but I think I hit the secondary rate limit somehow. Had multiple workspaces open that each requested a new signin to Github for the extension. After that each one had a similar log output to my previews comment and requested I sign in again after a short moment. In the end, I needed to disable GitHub Pull Requests and Issues for an hour, that resolved it.
Until I looked at the logs it wasn't obvious to me what the issue was.

With the GitHub PR extension version 0.38.* (and many 0.37.*) versions, we do ask for sign in again when we hit a rate limit error. https://github.com/microsoft/vscode-pull-request-github/issues/2741#issuecomment-1024164158 indicated that forcing re-auth fixes the rate limit issue in some cases. It looks like that isn't always true though.
Repeatedly asking for sign-in isn't good, so if the rate limit issue occurs twice in a row we shouldn't prompt for sign in again. I'm not sure what else I can do from the extension besides show an error and ask users to wait if this occurs twice in a row though. Still not a great experience.

With the GitHub PR extension version 0.38.* (and many 0.37.*) versions, we do ask for sign in again when we hit a rate limit error. microsoft/vscode-pull-request-github#2741 (comment) indicated that forcing re-auth fixes the rate limit issue in some cases. It looks like that isn't always true though.

I'm not sure it actual was the re-auth that fixed it. Maybe just the time between trying again.
Tbh though, I'm not an expert. Just my naive understanding that a re-auth usually doesn't change API limits.

Repeatedly asking for sign-in isn't good, so if the rate limit issue occurs twice in a row we shouldn't prompt for sign in again. I'm not sure what else I can do from the extension besides show an error and ask users to wait if this occurs twice in a row though. Still not a great experience.

Asking to sign-in again suggested to me that the auth itself failed, which wasn't the case. A better prompt message would definitely help. Furthermore, after the third and forth re-auth I tried Cancel but that just triggered the prompt again, in an endless loop.
Another aspect would be the API calls itself. From my understanding, it doesn't make much sense to fetch an API endpoint again if you already got a limit error the first time. That's however what the extension did, at least the log suggests as much.

Hey @TylerLeonhardt, this issue might need further attention.
@BestSpark687090, you can help us out by closing this issue if the problem no longer exists, or adding more information.

@BestSpark687090 @cdce8p have you seen this issue recently?

no not really

On Jun 3, 2022, at 12:04 PM, Tyler James Leonhardt @.***> wrote:

@BestSpark687090 @cdce8p have you seen this issue recently?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

@BestSpark687090 @cdce8p have you seen this issue recently?

Not recently. However, I'm using a slightly different workflow now. So don't know if it's truly fixed.
Guess it's safe to close this issue. We can open a new one if it comes back.

Ok I'll close this then but definitely feel free to reach out if you see it again!


PHP 8.2 is not supported

Running PHP 8.2.6 (from remi repository on Centos8) and it's working here with current release of microweber.


Warning when using MLVision

Code:
let vision = Vision.vision()
let options = VisionFaceDetectorOptions()
options.contourMode = .all
options.performanceMode = .accurate
let faceDetector = vision.faceDetector(options: options)

let image = VisionImage(image: $0)
faceDetector.process(image) { faces, error in
  guard error == nil, let faces = faces, !faces.isEmpty else { return }
  for face in faces {
    if face.contour(ofType: .face) != nil {
      // do something
    }
  }
}

Xcode warning:

+[FBMLx_CCTClearcutUploader crashIfNecessary] Multiple instances of CCTClearcutUploader were instantiated. Multiple uploaders function correctly but have an adverse affect on battery performance due to lock contention.

Are there any duplicate class errors printed to console?

@morganchen12 nope.
The weird thing is that the message is appearing twice, and in behind the TensorFlow initializer.

+[FBMLx_CCTClearcutUploader crashIfNecessary] Multiple instances of CCTClearcutUploader were instantiated. Multiple uploaders function correctly but have an adverse affect on battery performance due to lock contention.
Initialized TensorFlow Lite runtime.
+[FBMLx_CCTClearcutUploader crashIfNecessary] Multiple instances of CCTClearcutUploader were instantiated. Multiple uploaders function correctly but have an adverse affect on battery performance due to lock contention.

The message appearing twice is normal, since each CCTClearcutUploader instance will report that a second one is running. Is this reproducible with the sample in this repository?


Fix for 3840

Prior to this fix, you could crash the runtime if you sent a val struct wrapper in an iso class. For example:
use "collections"

struct val Foo

class Bar
  let f: Foo = Foo

actor Main
  new create(env: Env) =>
    for i in Range(0, 20000) do
      inspect(recover Bar end)
    end

  be inspect(wrap: Bar iso) =>
    None // Do something with wrap.f

Closes #3840

@ponylang/committer I'm finding a 0.7% performance degradation from this fix as is on the performance test machine.
Here's the basic command being run in case it means anything to you:
sudo cset proc -s user -e numactl -- -C 1-14,15 ./baseline/3840 --pingers 320 --initial-pings 5 --report-count 1 --report-interval 600 --ponynoblock --ponynoscale --ponypinasio --ponypin --ponymaxthreads=14

Roughly:

cpu 0 is for kernel and other system processes
cpu's 1-15 are for the application
cpu's 1-14 are for scheduler threads
cpu 15 is for asio

The runs are about 5 minutes (give or take a few nanos) in length.
We are using the following runtime options:
--ponynoblock --ponynoscale --ponypinasio --ponypin --ponymaxthreads=14
I'm going to try some other configurations to see if the same small degradation holds. If pony committers agree this is an acceptable perf lose to fix the bug (I think it is), I'll play around with changing the layout of fields in:
typedef struct object_t
{
  void* address;
  size_t rc;
  uint32_t mark;
  bool immutable;
  pony_type_t* type;
} object_t;

to see if changing the location of type makes a perf difference. I doubt it will, but its worth a try.

I'll look into moving around where type additional field is in object map to see if it has a performance impact. I doubt it will but, it's worth checking and these perf tests are easy to do while watching TV or something.

Hi @SeanTAllen,
The changelog - fixed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.
Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 3993.md to match the number of this pull request.
The basic format of the release notes (using markdown) should be:
## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

There's no difference I can see when moving where in objectmap the type is located, so I'm leaving as-is at the end.


Demo for "Mixed-integer quadratic program" can not run

Describe the bug
A clear and concise description of what the bug is.
In the Official website ”Mixed-integer quadratic program“，the following demo is not work,it can't run.
when I run, it produce the following error:
cvxpy.error.SolverError: Either candidate conic solvers (['GLPK_MI']) do not support the cones output by the problem (SOC, NonNeg, Zero), or there are not enough constraints in the problem.
I don't know how to figure out,help

Do prob.solve(solver=cp.ECOS_BB).

when I use ECCOS_BB, it produce the following error:
UserWarning: Solution may be inaccurate. Try another solver, adjusting the solver settings, or solve with verbose=True for more information.

Make sure you're using the latest cvxpy.


update download page to 0.29.0 and use bidders as source of truth

Don't merge just review please :)

Weird, it seems to correct this issue if I delete the following line from download.md:


in web emoji not showing color only grey

i am trying to use this package but in web its showing grey color emoji

Similar issue exist already
https://github.com/Fintasys/emoji_picker_flutter/issues/136


How to handle new account when pin global

@brenzi @clangenb I would like to discuss, how we should handle the global pin when a user wants to add a new account in the app.
I thought, if a user wants to add an account, and an account already exists, the user will be propt to enter the pin (if cachedPin empty).
Also, the new account will just take over the same pin as before and no pin field will be displayed on account creation.
Else, if no account exists, the user will create an account and set the global pin.

If account exists, why re-import it? Just say it already exists. That's all
And why "take over pin from existing account"? The pin has nothing to do with individual accounts if it is stored globally once

yes

just know @brenzi: pin global is not really possible without big complications, so we are going for same pin for all accounts

This is a hack and not acceptable midterm

I quickly want to summarize the current conditions, and why things are like that:
The keystore logic is the one from @polkadot/api,. There we use the keyring, which is essentially a map with all the keys. When  a key is stored, it will be added to the keyring and encrypted with the supplied PIN. This is the reason, why essentially every account has its individual PIN. Hence, when we change the PIN, we currently need to iterate through all the accounts in the keyring, decrypt them with the old PIN, and encrypt them again with the new PIN.
I guess this is unnecessarily complex, and we should change that in the future, but it needs some thinking. I will open another issue for that but will close this one as the discussion went astray from the original question.


Dry running

Closes paritytech/substrate#37
Relevant problems: https://github.com/paritytech/polkadot-sdk/issues/123

it will panic, yes, but it is the best we can do now (at least this is my conclusion after 2h digging in the Substrate code)... I requested Parity to provide a true dry-run mechanism, and once it is there, I will replace it here


NearContract deletion, init, refactoring

Init() is not required by default, now we have a requireInit flag in NearBindgen
No need in default() function, deleted
No need to extend NearContract. Class is deleted, and logic is moved to NearBindgen
Added @initialize decorator for init functions. Function panics if called more then  once
Now constructor is expected to be simplistic. No parameters, no side effects, only variable declarations

@ailisp tests added, merging.


Already borrowed panic (BorrowMutErr) during cargo update

Problem
When running cargo update, I encountered the following crash:

With the error being:
thread 'main' panicked at src/cargo/util/context/mod.rs:412:20:
already borrowed: BorrowMutError

Steps

Clone this repo: https://github.com/TheLostLambda/smithereens
Switch to the cargo-bug branch
Run cargo update
Crash!

Possible Solution(s)
No response
Notes
Happy to help debug and gather more information if there are any issues reproducing!
Version
cargo 1.79.0-nightly (a510712d0 2024-03-25)
release: 1.79.0-nightly
commit-hash: a510712d05c6c98f987af24dd73cdfafee8922e6
commit-date: 2024-03-25
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

Also, I've just tested with the beta release of cargo, and it works fine! It would seem that the bug has been introduced / exposed between this version and now:
cargo 1.78.0-beta.2 (2fe739fcf 2024-03-15)
release: 1.78.0-beta.2
commit-hash: 2fe739fcf16c5bf8c2064ab9d357f4a0e6c8539b
commit-date: 2024-03-15
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

And I think that makes this the diff containing potential trouble-makers...
https://github.com/rust-lang/cargo/compare/2fe739fc...a510712
It's a big one, so perhaps someone with a bit more time / knowledge of the cargo internals will have to git bisect!

This was likely a duplicate of #13646 and fixed in #13647.

@epage I think you're probably right — I'll try with the current git version and let you know!
If it is fixed, then I'll close this!

Looks to be fixed! Thanks for the rapid response @epage !


Compatibility with Angular

Using this library in an Angular app results in the following errors:
Error: node_modules/cloudinary-build-url/dist/cjs/url.d.ts:1:104 - error TS2307: Cannot find module '@cld-apis/types' or its corresponding type declarations.

    1 import type { CloudConfig, TransformerOption, TransformerVideoOption, ResourceType, StorageType } from '@cld-apis/types';
                                                                                ~~~~~~~~~~~~~~~~~
    node_modules/cloudinary-build-url/dist/cjs/transformers/index.d.ts:1:37 - error TS2307: Cannot find module '@cld-apis/types' or its corresponding type declarations.

    1 import type { Transformation } from '@cld-apis/types';
                                          ~~~~~~~~~~~~~~~~~
    node_modules/cloudinary-build-url/dist/cjs/index.d.ts:1:46 - error TS2307: Cannot find module '@cld-apis/types' or its corresponding type declarations.

    1 import type { CldOptions, CloudConfig } from '@cld-apis/types';
                                                   ~~~~~~~~~~~~~~~~~
    node_modules/cloudinary-build-url/dist/cjs/index.d.ts:11:27 - error TS2307: Cannot find module '@cld-apis/types' or its corresponding type declarations.

    11     resourceType?: import("@cld-apis/types").ResourceType;
                                 ~~~~~~~~~~~~~~~~~
    node_modules/cloudinary-build-url/dist/cjs/index.d.ts:14:26 - error TS2307: Cannot find module '@cld-apis/types' or its corresponding type declarations.

    14     storageType?: import("@cld-apis/types").StorageType;

Found the answer:
npm i -D @cld-apis/types
Could you update the docs (incl the readme and the npm package) to make this more obvious? :) thank you 🙏

Sure @tpiros


Fix code editor not always centering to bookmarks

Turns out I missed a case in #34048, which made the centering unreliable.

Thanks!


Scenario rendering does not work with given sex

Hi,
I am trying to run the workflow for datasets of cell lines obtained with the TSO500 panel on a Nextseq 550 device.
It gives an error for the varlociraptor call stating: Error: samples.tumor.sex: invalid type: sequence, expected string or singleton map at line 21 column 5.
Unfortunately, it fails in creating an appropriate scenario. The scenario file under results/scenario/HD789.yaml looks like this:
species:
  heterozygosity: 0.001
  germline-mutation-rate: 1e-3
  ploidy:
    male:
      all: 2
      X: 1
      Y: 1
    female:
      all: 2
      X: 2
      Y: 0
  genome-size: 3.5e9
expressions:
  ffpe_subst: C>T | G>A
samples:
  tumor:
    resolution: 0.01
    universe: '[0.0,1.0]'
    sex: !!python/object/apply:numpy.core.multiarray.scalar
    - &id001 !!python/object/apply:numpy.dtype
      args:
      - f8
      - false
      - true
      state: !!python/tuple
      - 3
      - <
      - null
      - null
      - null
      - -1
      - -1
      - 0
    - !!binary |
      AAAAAAAA+H8=
    contamination:
      by: normal
      fraction: .nan
  normal:
    universe: 0.0 | 0.5 | 1.0
    sex: !!python/object/apply:numpy.core.multiarray.scalar
    - *id001
    - !!binary |
      AAAAAAAA+H8=
events:
  somatic_tumor_high: normal:0.0 & tumor:[0.1,1.0]
  germline: (normal:0.5 & tumor:0.5) | (normal:1.0 & tumor:1.0)
  ffpe_artifact: ($ffpe_subst) & tumor:]0.0,0.05[
  somatic_tumor_low: normal:0.0 & ((($ffpe_subst) & tumor:]0.05,0.1[) | (!($ffpe_subst)
    & tumor:]0.0,0.1[))

I suspected that the configuration of the sex is wrong, which is not explained in the documentation, but trying it with "NA", "female" or "male" always gives the same result. For this sample, I do not know the given sex as it is a mixture of cell lines.
Here are my configuration files:
samples.tsv:
sample_name	alias	group	platform	purity	panel	sex	ffpe
HD789	tumor	HD789	ILLUMINA	NA	TSO500 male 0

units.tsv:
sample_name	unit_name	fq1	fq2	sra	adapters	umis
HD789	L001	HD789-DNA_S2_L001_R1_001.fastq.gz	HD789-DNA_S2_L001_R2_001.fastq.gz	NA	"-a CTGTCTCTTATACACATCT -A CTGTCTCTTATACACATCT"
HD789	L002	HD789-DNA_S2_L002_R1_001.fastq.gz	HD789-DNA_S2_L002_R2_001.fastq.gz	NA	"-a CTGTCTCTTATACACATCT -A CTGTCTCTTATACACATCT"
HD789	L003	HD789-DNA_S2_L003_R1_001.fastq.gz	HD789-DNA_S2_L003_R2_001.fastq.gz	NA	"-a CTGTCTCTTATACACATCT -A CTGTCTCTTATACACATCT"
HD789	L004	HD789-DNA_S2_L004_R1_001.fastq.gz	HD789-DNA_S2_L004_R2_001.fastq.gz	NA	"-a CTGTCTCTTATACACATCT -A CTGTCTCTTATACACATCT"

config.yaml:
samples: config/samples.tsv

units: config/units.tsv

# Optional BED file with target regions
# uncomment to use
target_regions: "/home/kai/ukd/projects/TSO500/data/TSO500_manifest_GRCh38.bed"

primers:
  trimming:
    activate: false
    # path to fasta files containg primer sequences
    primers_fa1: "path/to/primer-fa1"
    primers_fa2: "path/to/primer-fa2"
    # optional primer file allowing to define primers per sample
    # overwrites primers_fa1 and primers_fa2
    # the tsv file requires three fields: panel, fa1 and fa2 (optional)
    tsv: ""
    # Mean insert size between the outer primer ends.
    # If 0 or not set the bowtie default value of 250 will be used
    library_length: 0

calc_consensus_reads:
  # Set to true for merging PCR duplicates and overlapping reads using rbt:
  # https://github.com/rust-bio/rust-bio-tools
  activate: true

# Estimation of mutational burden.
mutational_burden:
  # Size of the sequenced coding genome for mutational burden estimation
  # Attention: when doing panel sequencing, set this to the
  # CAPTURED coding genome, not the entire one!
  coding_genome_size: 1.94e6

report:
  max_read_depth: 250
  stratify:
    # if stratification is deactivated, one tabular report for all
    # samples will be created.
    activate: false
    # select a sample sheet column for stratification, e.g. the tumorboard session
    by-column: session

params:
  varlociraptor:
    # add extra arguments for varlociraptor call
    # For example, in case of panel data consider to omit certain bias estimations
    # which might be misleading because all reads of an amplicon have the same start
    # position, strand etc. (--omit-strand-bias, --omit-read-position-bias,
    # --omit-softclip-bias, --omit-read-orientation-bias).
    call: ""
    # Add extra arguments for varlociraptor preprocess. By default, we limit the depth to 200.
    # Increase this value for panel sequencing!
    preprocess: "--max-depth 200"
  freebayes:
    min_alternate_fraction: 0.01 # Reduce for calling variants with lower VAFs
``

Thanks for reporting. I'll try to reproduce that.


Weather effects

How it works:

Map gets weathercomponent which is a weatherprototype.
Weatherprototype specifies what tiles are included for weather (anything not on a grid is assumed included).
These tiles are then stenciled out which supports planetmaps / grids. This also lets us do stuff like radstorm where certain tiles aren't affected.
Audio is done via floodfilling to nearest tile to use for volume.

Outstanding:

[x] Fix the audio situation
[x] Actually do the audio floodfill
[x] Fix rotation
[x] Cache frames
- [ ] Weather effects for e.g. rad storms
[x] Cleanup
[x] RGA attributions

:cl:

add: Weather has been added to the game.

Should be okay for review now I think.


Option --dryrun to perform dry run

When --dryrun is specified, targets are not executed but simply marked as Success. It follows the dependencies, but actually do nothing.

Thank @whywhy36 for contributing #17


Move calldata limit validation in the Linea plugin

that test is flaky, need to be reviewed, after a rerun it passed


First draft of supplementary classes for dummy_animal_module

Description
This contains the supplementary classes for the dummy animal module, accompanying tests, and the animals_schema.json. These are classes for plants, soils, and carcasses used for testing functions of the animal class. The plant class contains simple functions for growth (increasing energy storage) and death.
These supplementary classes are being uploaded first because the animals class contains references to them and I needed to break up the work I'd done into smaller chunks for reviewing.
Fixes # (issue)
Type of change

[X] New feature (non-breaking change which adds functionality)
[ ] Optimization (back-end change that speeds up the code)
[ ] Bug fix (non-breaking change which fixes an issue)

Key checklist

[X] Make sure you've run the pre-commit checks: $ pre-commit run -a
[X] All tests pass: $ poetry run pytest

Further checks

[X] Code is commented, particularly in hard-to-understand areas
[X] Tests added that prove fix is effective or that feature works

@TaranRallings I've added Diego as a reviewer too, in case he wants to add his two cents.
I'll take a look now

Also note that we're moving to a structure of having a models folder, so this should be in virtual_rainforest/models/animals

Codecov Report

Merging #153 (d7f1d4f) into feature/animal_module (6f2da0d) will decrease coverage by 0.56%.
The diff coverage is 86.48%.

:exclamation: Current head d7f1d4f differs from pull request most recent head cb4cb07. Consider uploading reports for the commit cb4cb07 to get more accurate results

@@                    Coverage Diff                    @@
##           feature/animal_module     #153      +/-   ##
=========================================================
- Coverage                  94.06%   93.51%   -0.56%
=========================================================
  Files                         11       13       +2
  Lines                        472      509      +37
=========================================================
+ Hits                         444      476      +32
- Misses                        28       33       +5

Impacted Files
Coverage Δ

...l_rainforest/models/animals/dummy_animal_module.py
82.14% <82.14%> (ø)

virtual_rainforest/models/animals/__init__.py
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Correction for raw affiliation BIOPASS, CBGP-IRD, ISRA, UCAD, CIRAD, Campus de Bel-Air, Dakar, Senegal; CBGP, IRD, CIRAD, INRAE, Institut Agro, Univ Montpellier,; CBGP, IRD, INRAE, CIRAD, Montpellier SupAgro, Univ Montpellier, Montpellier, France

Correction needed for raw affiliation BIOPASS, CBGP-IRD, ISRA, UCAD, CIRAD, Campus de Bel-Air, Dakar, Senegal; CBGP, IRD, CIRAD, INRAE, Institut Agro, Univ Montpellier,; CBGP, IRD, INRAE, CIRAD, Montpellier SupAgro, Univ Montpellier, Montpellier, France
raw_affiliation_name: BIOPASS, CBGP-IRD, ISRA, UCAD, CIRAD, Campus de Bel-Air, Dakar, Senegal; CBGP, IRD, CIRAD, INRAE, Institut Agro, Univ Montpellier,; CBGP, IRD, INRAE, CIRAD, Montpellier SupAgro, Univ Montpellier, Montpellier, France
new_rors: 05q3vnk25;05kpkpg04;051escj72;03rnk6m14;003vg9w96;05h7ddb14
previous_rors: 05q3vnk25;05kpkpg04;051escj72;03rnk6m14;003vg9w96
works_examples: W4382862923
contact: cb6fd8d1b3a67dad0d4ccf75231618b5:609d589164a046c63685d09df689bb386fad @ inrae.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-18. The new affiliations should be visible within the next 7 days.


Why Is The macOS Adguard So Badly Designed?

As a fully paid personal lifetime user of the Adguard macOS app I am personally disgusted that the Adguard macOS app lacks features found in the 100% free Extension.
The Adguard macOS app has not got these features:

No recording of Cosmetic/Custom Rules which have Blocked things on webpages in the Filtering Log.

The overall design of the macOS app Filter Log is quite bad, the colours used to designate various Rules are poorly chosen. The Extension Filter Log is much more user friendly and does indeed record blocked cosmetic elements or items blocked via Cosmetic/User Custom Rules

No count of Total Number of Filter Rules in individual Filter Lists or a Total Number of All Filter Rules

No option to use Optimized Filter Lists.

Why has the development of the macOS app NOT been updated to provide features which are equal to or better than the Extension.
I fully acknowledge the macOS system app is far more technically capable than any Extension.
So why is the macOS app user interface is lacking features that the Extension contains and why is the macOS app is so very badly designed and that it is need of a major overhaul.
The Technical Issue of the Filtering Logs NOT recording Cosmetic/Custom User Rules has been known by Adguard for at least 5 years and they done absolutely NOTHING to fix this.
The folks at Adguard seem to have NO INTEREST in fixing this.
The fact is that a Filtering Log which is incompetent and lacks features creates issues when items on a webpage are blocked and you have NO RECORDS TO SHOW WHAT COSMETIC ITEMS ARE BLOCKED, This makes it a very difficult and time consuming task to find out what is blocking parts of a webpage.
People whom are paying for a License to use a paid product deserve much better.
The customers of Adguard are paying hard earned cash for this product and in return we get a very badly designed product, which Adguard is not improving, the problem with the Filtering Log has been present for 5 very long years now.
AFTER 5 YEARS THERE IS STILL NO ACTION TAKEN BY ADGUARD TO FIX THIS AT ALL.
Some features may indeed may be more difficult to implement in a macOS app.
But Adguard  spent a lot of time and effort developing the Manifest V3 Extension which was very difficult and time consuming to develop due to the restrictions of Manifest V3.
Adguard gets ABSLOUTELY NO REVENUE/INCOME FROM A FREE EXTENSION.
Yet they gave this FREE EXTENSION priority treatment and left the paid for macOS app languish and it still sorely lacks features that it needs.
Adguard depends on revenue from customers whom pay for a license to use the full system macOS app and yet Adguard ignores what their paying customers want by still refusing to introduce improvements to the Filtering Log after 5 very long years and there is still no indication that Adguard is ever going to improve and develop their macOS app.
What type of business model do they run, when they offend paying customers of the macOS app by dragging their heels and not introducing much needed features
But instead of spending time and research on development of the macOS app
Adguard is taking paying customers for granted and allowing the development of the macOS app to languish and they can't even be bothered giving their paid customers a full featured top quality app.

Duplicate of #180


NullPointerException running liberty:run with SpringBoot jar module

[INFO] CWWKM2185I: The liberty-maven-plugin configuration parameter "appsDirectory" value defaults to "dropins".
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.921 s
[INFO] Finished at: 2020-09-17T21:50:04+08:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.2:run (default-cli) on project Dragonheaven: null: MojoExecutionException: NullPointerException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

I transferred this issue from https://github.com/OpenLiberty/guide-maven-multimodules to ci.maven because it is not related to the Maven Multimodules guide. I think it relates to the LMP run command and I can simply reproduce the problem when doing the following:

add the following configuration  for the LMP as https://github.com/OpenLiberty/ci.maven/issues/935#issuecomment-694308860

                 <groupId>io.openliberty.tools</groupId>
                 <artifactId>liberty-maven-plugin</artifactId>
                 <version>3.2</version>
+        <configuration>
+             <assemblyArtifact>
+                <groupId>io.openliberty</groupId>
+                <artifactId>openliberty-runtime</artifactId>
+                <version><IP_ADDRESS></version>
+                <type>zip</type>
+             </assemblyArtifact>
+            <installAppPackages>spring-boot-project</installAppPackages>
+        </configuration>
             </plugin>

run mvn install
run mvn liberty:run

The liberty-maven-plugin support for SpringBoot JAR modules assumes you'll also be configuring the spring-boot-maven-plugin.
See the guide and the doc on this.
The NullPointerException happens when the liberty-maven-plugin fails to find the expected spring-boot-maven-plugin goal(s) in the build.

Thanks for the analysis @scottkurz. I'll see if we can send a helpful error in this situation rather than let the NPE happen.

@Bluedragonplayz2 In the next release of the plugin, you will see the following error instead of a NPE in this scenario.


Get the below message while created Azure Quantum on any provider

invalidResourceType","message":"The resource type could not be found in the namespace 'Microsoft.Quantum' for api version

Hi @shreyas-19, thank you for filling this issue. Unfortunately, this repository is only for issues related to the documentation. To make sure you get the best level of support, it would be great if you could
report your issue via [https://ms.portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest] or Azure Q&A(https://docs.microsoft.com/en-us/answers/topics/azure-quantum.html) if you don't have access to an Azure support plan


Encoder is not starting

i m using decklink recorder as input,
after configuring hls output encoder not starting, where am i doing wrong

this issue is with my installation with bmd drivers
issue resolved


Message conversions docs - conversions.md

Covering the new conversion rules introduced with the message containers PR.
Complementary fixes in https://github.com/rabbitmq/rabbitmq-server/pull/9830

The forced push was a rebase.


v0.6.2 breaks offline data generation

Bug Description
In upgrading from sqlx 0.6.1 to 0.6.2, the cargo sqlx prepare command, run on our workspace, now generates the following (and only the following) in sqlx-data.json:
{
  "db": "PostgreSQL"
}

Previously this was ~2k lines of query data. The actual command we're running is:
cargo sqlx prepare --merged -- --all-features --all-targets

The --check command also fails.
Downgrading to sqlx 0.6.1 solves the issue.
Minimal Reproduction
I have not managed to make a minimal reproduction yet.
Info

SQLx version: 0.6.2
SQLx features enabled:

    "chrono",
    "ipnetwork",
    "json",
    "macros",
    "migrate",
    "offline",
    "postgres",
    "runtime-tokio-rustls",
    "uuid",
    "tls",

Database server and version: postgres 14.3
Operating system: NixOS
rustc --version: rustc 1.63.0 (4b91a6ea7 2022-08-08)

Please upgrade sqlx-cli to 0.6.2 and try again.

As mentioned, upgrading sqlx-cli to 0.6.2 should solve it: cargo install -f sqlx-cli --version 0.6.2, or just cargo install -f sqlx-cli for the latest.
This is because #2069 changed the folder layout of the query metadata files before being combined in cargo sqlx prepare.

Just noting that it might be useful to add a note to the CHANGELOG mentioning this. I went digging through there before I opened this issue, and while I saw there were a couple of PRs related to offline data generation, nothing stuck out to me that made me think of upgrading sqlx-cli


Error: 'BedrockRuntime' object has no attribute 'converse_stream'

Got this after installing the plugin in an environment that already had an outdated version of boto3.

Not sure which version of boto3 added that API so I'll pin to at least the very most recent: https://pypi.org/project/boto3/1.35.74/