Role assignment can't be created because the service principal "doesn't exist"

hi,
I'm having a troublesome issue where I am creating a service principal using graph-rbac library, and then creating a role assignment using auth-mgmt library.
However, I keep getting issues in my pipelines where it works every now and then, but most of the times it fails. What does it fail with:
INFO:Azure.Azure:Creating infra-user role assignment on service principal for acceptance environment ..
INFO:Azure.Azure:Verifying existence of service principal for acceptance environment ..
INFO:Azure.Azure:Service principal for 005-test-infra-user verified on acceptance, continuing ..
ERROR:Azure.Azure:Failed to assign the role assignment for infra-user in acceptance environment
Traceback (most recent call last):
  File "<input>", line 37, in create_azure_serviceprincipal_roleassignment
  File "C:\Applications\Python37\lib\site-packages\azure\mgmt\authorization\v2018_01_01_preview\operations\_role_assignments_operations.py", line 332, in create
    raise exp
msrestazure.azure_exceptions.CloudError: Azure Error: PrincipalNotFound
Message: Principal 234-54566-324-76324 does not exist in the directory ##############################.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<input>", line 33, in <module>
  File "<input>", line 43, in create_azure_serviceprincipal_roleassignment
AzureAuthorization: Error assigning the role to the service principal

Now I actually have a check built-in to the code that verifies if the service principal exists. But we can also see in the log output that I just created the service principal, then verify if it exists, and then try to create the role assignment.
The code to verify if the service principal exists:
def verify_sp_exists(environment, service_principal, stack_slug, role_name):
    try:
        logger_azure.info(
            'Verifying existence of service principal for %s environment ..', environment)
        sp_verification = graph_client.get(environment).service_principals.get(
            object_id=service_principal.object_id)
    except AttributeError:
        logger_azure.info(
            'Service principal %s-%s does not exist on %s, trying again ..', stack_slug, role_name, environment)
    if service_principal.object_id == sp_verification.object_id:
        logger_azure.info(
            'Service principal for %s-%s verified on %s, continuing ..', stack_slug, role_name, environment)
    while service_principal.object_id != sp_verification.object_id:
        logger_azure.info(
            'Service principal could not be verified on %s, trying again ..', environment)
        sp_verification = graph_client.get(environment).service_principals.get(
            object_id=service_principal.object_id)
        if service_principal.object_id == sp_verification.object_id:
            logger_azure.info(
                'Service principal %s-%s verified on %s..', stack_slug, role_name, environment)
            break

And this code is called during the creation of the role assignment, to make sure it is there before I try to create it:
def create_azure_serviceprincipal_roleassignment(resource_group, service_principal, role_definition,
                                                 role_name):
    for environment in ENVIRONMENTS:
        logger_azure.info(
            'Checking if %s role assignment already exists on service principal with scope %s for %s environment ..',
            role_name, resource_group.get(environment).name, environment)
        role_assignment = {'role_definition_id': ra.role_definition_id for ra in
                           auth_client.get(environment).role_assignments.list_for_resource_group(
                               resource_group_name=resource_group.get(environment).name,
                               filter=f"principalid eq '{service_principal.get(environment).object_id}'") if
                           ra.role_definition_id == role_definition.get(environment).get(
                               role_name)}
        print(f"The role assignment found = {role_assignment.get('role_definition_id')}")
        print(f"Going to match against: {role_definition.get(environment).get(role_name)}")
        if role_assignment.get('role_definition_id') == role_definition.get(environment).get(
                            role_name):
            logger_azure.info(
                '%s role assignment already exists on service principal for %s environment ..',
                role_name, environment)
        else:
            try:
                logger_azure.info(
                    'Creating %s role assignment on service principal for %s environment ..',
                    role_name, environment)

                verify_sp_exists(environment=environment,
                                 service_principal=service_principal.get(environment),
                                 stack_slug=stack_slug,
                                 role_name=role_name)

                auth_client.get(environment).role_assignments.create(
                    resource_group.get(environment).id,
                    uuid4(),
                    {
                        'role_definition_id': role_definition.get(environment).get(
                            role_name),
                        'principal_id': service_principal.get(environment).object_id
                    }
                )
                logger_azure.info('Succesfully created role assignment for %s environment ..', environment)
            except CloudError:
                logger_azure.error('Failed to assign the role assignment for %s in %s environment', role_name, environment)
                raise AzureAuthorization('Error assigning the role to the service principal')

But still it keeps failing, and my gut is telling me this is because I'm doing the existence check using the graph library. While the role assignment is created using the auth library. And somehow the auth library is not able to see it got created yet?
Does someone have a suggestion on how to fix this to prevent the role assignment creation from ever failing on a "non-existing" service principal. Note the quotation marks, because I am 100% positive the service principal exists.

So I am currently doing the following:
def create_azure_serviceprincipal_roleassignment(resource_group, service_principal, role_definition,
                                                 role_name):
    for environment in ENVIRONMENTS:
        logger_azure.info(
            'Checking if %s-%s role assignment already exists on service principal with scope %s for %s environment ..',
            stack_slug, role_name, resource_group.get(environment).name, environment)
        role_assignment = {'role_definition_id': ra.role_definition_id for ra in
                           auth_client.get(environment).role_assignments.list_for_resource_group(
                               resource_group_name=resource_group.get(environment).name,
                               filter=f"principalid eq '{service_principal.get(environment).object_id}'") if
                           ra.role_definition_id == role_definition.get(environment).get(
                               role_name)}
        print(f"Going to match against: {role_definition.get(environment).get(role_name)}")
        print(f"The role assignment found = {role_assignment.get('role_definition_id')}")
        if role_assignment.get('role_definition_id') == role_definition.get(environment).get(
                            role_name):
            logger_azure.info(
                '%s-%s role assignment already exists on service principal for %s environment ..',
                stack_slug, role_name, environment)
        else:
            try:
                logger_azure.info(
                    'Creating %s-%s role assignment on service principal for %s environment ..',
                    stack_slug, role_name, environment)

                time.sleep(5)
                verify_sp_exists(environment=environment,
                                 service_principal=service_principal.get(environment),
                                 stack_slug=stack_slug,
                                 role_name=role_name)
                time.sleep(5)

                auth_client.get(environment).role_assignments.create(
                    resource_group.get(environment).id,
                    uuid4(),
                    {
                        'role_definition_id': role_definition.get(environment).get(
                            role_name),
                        'principal_id': service_principal.get(environment).object_id
                    }
                )
                logger_azure.info('Successfully created role assignment for %s environment ..', environment)
            except CloudError as error:
                logger_azure.info(
                    'First attempt to assign the role assignment for %s in %s environment failed .. retrying ..',
                    role_name,
                    environment)
                if f'does not exist in the directory' in error.message:
                    try:
                        logger_azure.info(
                            'Creating %s-%s role assignment on service principal for %s environment ..',
                            stack_slug, role_name, environment)

                        time.sleep(5)
                        verify_sp_exists(environment=environment,
                                         service_principal=service_principal.get(environment),
                                         stack_slug=stack_slug,
                                         role_name=role_name)
                        time.sleep(5)

                        auth_client.get(environment).role_assignments.create(
                            resource_group.get(environment).id,
                            uuid4(),
                            {
                                'role_definition_id': role_definition.get(environment).get(
                                    role_name),
                                'principal_id': service_principal.get(environment).object_id
                            }
                        )
                        logger_azure.info('Successfully created role assignment for %s environment ..', environment)
                    except CloudError as error:
                        logger_azure.info('Second attempt failed .. retrying ..', role_name, environment)
                        if f'does not exist in the directory' in error.message:
                            try:
                                logger_azure.info(
                                    'Creating %s-%s role assignment on service principal for %s environment ..',
                                    stack_slug, role_name, environment)

                                time.sleep(5)
                                verify_sp_exists(environment=environment,
                                                 service_principal=service_principal.get(environment),
                                                 stack_slug=stack_slug,
                                                 role_name=role_name)
                                time.sleep(5)

                                auth_client.get(environment).role_assignments.create(
                                    resource_group.get(environment).id,
                                    uuid4(),
                                    {
                                        'role_definition_id': role_definition.get(environment).get(
                                            role_name),
                                        'principal_id': service_principal.get(environment).object_id
                                    }
                                )
                                logger_azure.info('Successfully created role assignment for %s environment ..',
                                                  environment)
                            except CloudError:
                                logger_azure.info('Final attempt failed .. re-run for stack %s  ..', role_name,
                                                  environment, stack_slug)
                                raise AzureAuthorization('Error assigning the role to the service principal')
                else:
                    raise AzureAuthorization('Error assigning the role to the service principal')

This helps me to circumvent getting the error, but I realy don't like this way of coding ..

Hi @MMollyy
That's mostly the approach the CLI is using as well:
https://github.com/Azure/azure-cli/blob/4d5b1a942e48ce6f8674420f2b18d50f19ed860e/src/azure-cli/azure/cli/command_modules/role/custom.py#L1344-L1365
They comment it as "waiting for replication to do be done", so my guess is that because AAD and Azure Authorization are two different entities, there is some synchronization ongoing here. I'm sorry that it creates a burden, I keep this issue open for the service teams to investigate.

Hey @lmazuel ,
thanks. I had figured as much, thanks for confirming. I would definitely like to hear/read back on the results of that investigation.


ALPINE 3.20.x with Python 12 and  aiohttp

Python 12 has problem with aiohttp >3.9 but is required aiohttp < 3.9 and >=3.8

what about using https://github.com/aio-libs/aiohttp/releases/tag/v3.9.5

what about using https://github.com/aio-libs/aiohttp/releases/tag/v3.9.5
Hi @peppelinux !
I have set aiohttp>=3.9,<3.10. I'll do some tests :+1:

thank you @MdreW for the work made so far and the one you'r going to do

@peppelinux
All seem work fine and is fixed #140 ,  #139 and #138 . I open a pull request but before merge I open another issue with a proposal for run satosa with a normal user (no root)

@peppelinux All seem work fine and is fixed #140 , #139 and #138 . I open a pull request but before merge I open another issue with a proposal for run satosa with a normal user (no root)

Hi @peppelinux , I maintain separate this tread with the security enforcements question. I will set the pull request as ready for review.
I have worked this update for a week without problems :+1:


Don't generate all the storage API versions

Coverage remained the same at 3.954% when pulling ef75040fbab8fce44fb9b85ce6c5bda561130e8f on matthchr:feature/fix-build into 3de731fcec18248e30c70e959981ec5cc1049f0b on Azure:master.


jGrowl including its own jQuery v3 when imported via Yarn/Webpack

Hi there -- been a long-time user of jGrowl in a legacy Rails app that we're migrating to Yarn/Webpack for dependency management.
At the moment, when I include jGrowl in our package.json file:
"jgrowl": "^1.4.6",
and run yarn install, the jGrowl module that shows up in node_modules also brings along its own node_modules subfolder, including its own jQuery v3.6.0.
We've been using JGrowl version 1.4.6 for a while but have been back on jQuery 2.x... and have never noticed a problem. However, the jGrowl package.json specifies jQuery ^3.4.1.
So... as you can imagine Webpack then ends up loading two copies of jQuery: the global v2.x that we install first, and the version 3.4 brought along by jGrowl.
jGrowl is then being attached to this second v3 jQuery instead of the first v2.x jQuery we install and export as a global for use by our legacy JS... so our legacy JS cannot access jGrowl.
I've confirmed that jGrowl does work as expected if I manually delete jGrowl's node_modules folder -- that removes the conflicting copy of jQuery and everything appears to work.
While leads to two questions.

Is jGrowl only compatible with jQuery 3+?
Are you aware of any way to prevent Webpack from installing this second version of jQuery? I have tried defining aliases:

resolve: {
    alias: {
      'jquery': 'jquery/dist/jquery'
    }
  }

but that does not appear to make a difference.
Thanks in advance for any thoughts -- kind of miss the days when questions and issues were actually about using libraries, instead of just installing them...

In the meantime, I've found that installing 1.4.5 works fine -- it does not define a jQuery version dependency in its package.json. If 1.4.6 actually requires jQuery 3, then can close the issue on that basis.

@lawso017 would doing this cover your situation? https://github.com/stanlemon/jGrowl/pull/89/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R27-R30

Yes indeed -- believe that is a perfect solution!
https://nodejs.org/en/blog/npm/peer-dependencies/

Good deal. I'll merge this tonight and push a new version to NPM.

Note to future self -- also discovered that Yarn is part of the problem in this case; Yarn is aggressively loading sub-dependencies even when an existing dependency will satisfy a jQuery plugin's requirement.
Example... your project requires jQuery "^2.0.0"... a plugin requires jQuery ">1.8.0". If the current version of jQuery is 3.4.0, Yarn will install v3.4.0 for the plugin even though the already-available 2.2.0 would be sufficient.
So in addition to the library declaring jQuery as a "peer dependency", another solution when using Yarn is to specify a project-level version override via a "resolutions" block in the package.json file:
  "resolutions": {
    "jquery": "^2.0.0"
  }

For more info see here:
https://stackoverflow.com/questions/40108172/webpack-jquery-plugin-loading-its-own-instance-of-jquery


Design abstraction layer for multi-version protocols

With the addition of a lot of AIP 2.0 protocols, we're having multiple protocols that can have the same outcome. E.g. the connection and did exchange protocols both produce a connection record. We should look at an abstraction layer that takes away the complexity of dealing with multiple protocols from the user.
Protocols to look at:

[ ] Issue Credential V2
[ ] Present Proof V2
[ ] Out-of-band / DID Exchange

Questions

Should we create new modules and records for the new protocols versions? (rather not!)
How can we make the API for using a v1 or v2 version of the protocols as simple as possible

ideally only specifying e.g. protocolVersion: IssueCredential.v1
Making sure the user doesn't have to deal with CredentialRecord and CredentialRecordV2.
Example
(idea) what if we create a new record type for v2 (or other versions) that we move all v1 records to. Although a completely different message structure and possible content, v2 is mostly an extension to what was already possible in v1.
Example of abstracting v1 and v2: https://github.com/didx-xyz/aries-cloudapi-python/pull/114

await agent.credentials.offerCredential(connectionId, {
	protocolVersion: IssueCredential.v2,
	credentialTypes: {
		indy: {
			credentialDefintionId: "xxx",
		},
		vc: {
			"@type": []
			// other vc stuff
		}
	}
})

Or we could even go completely into the w3c structure for the api, deriving the indy structure from it, but I'm not sure if that's the way to go.
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",  // ← required by VC spec
    // ↓ defines primaryProof, nonRevocationProof, aggregateProof — common to all VPs derived from safe creds
    "https://github.com/hyperledger/ursa/libzmix/docs/safecreds-context-v1.9.jsonld",
  ],
  "type": "VerifiablePresentation", // ← required by VC spec
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",  // ← required by VC spec
        // ↓ proof req schema; could be URI, DID URI, inlined, or DIDComm msg URI. For now, prefer inline.
        "did:sov:NcYxiDXkpYi6ov5FcYDi1;version-id=abcxyz"
      ],
      "type": [
        "VerifiableCredential",  // ← required by VC spec
        "DerivedFromZKP" //  ← hardcoded by Indy; from safecreds-context
      ],
      "credentialSchema": {
        "id": "NcYxicryxQocYDi1e:2:gvt:1.0:TAG_1", // ← id of credential definition
        "type": "DerivedSchema" //  ← hardcoded by Indy; from safecreds-context
      },
      "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619", // ← looked up from cred def
      "issuanceDate": "2020-07-25T18:23:17.492Z", // ← random val before cred was derived (NOT from source)
      "credentialSubject": [{ //  ← array optional but always used to support multiple subjects
        "name": "Alex", // ← disclosed from primary_proof.eq_proof.revealed_attrs
        "height_cm": 175, // ← disclosed from primary_proof.eq_proof.revealed_attrs
        "predicate_age_GE_18": true // ← ????
      }],
      "proof": {
        "type": "AnonCredDerivedCredentialv1", // ← suggest name change to “SafeVCProofv1”
        "primaryProof": "cg7wLNSi48K5qNyAVMv1Ur8i...cSAsym2sgSk737", // ← base58 of primary_proof
        "nonRevocationProof": "mu6fg2JPU1HvSXsf...RSce53M6UwQCxYs3d2h" // ← base58 of non_revoc_proof
      }
  }],
  "proof": {
    "type": "SafeVPProof-v1", // ← hardcoded by Indy (first cut had “AnonCredPresentationProofv1”)
    "aggregateProof": "DgYdYMUYHUCEY5u5fK...j915Lt3hMzLHoPiPQ9sSVfRrs1D" // ← base58 of aggregated_proof
  }
}

Here is a possible design of the offerCredential public API.
The idea is not to create two separate methods for issue-credential v1 and v2, but offer a single method that allows for issuance using both protocol versions. For this reason we have a protocolVersion attribute, as @TimoGlastra had already proposed.
If the protocolVersion is set to 1, the credentialFormats object must contain the indy object. If the linkedDataProof object is also provided, it will be ignored as it's not supported by v1.
If protocolVersion is set to 2, then at least one of the formats must be provided. If both the indy and linkedDataProof formats are provided, the caller must make sure the two formats represent the same credential.
A offerCredential call for issue-credential v2 would then look something like this:
await agent.credentials.offerCredential({
  connectionId: "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  protocolVersion: 2,
  comment: "Some thoughts...",
  autoAcceptCredential: "contentApproved",
  credentialFormats: {
    indy: {
      credentialDefinitionId: "WgWxqztrNooG92RXvxSTWv:3:CL:20:tag",
      preview: {
        "@type": "issue-credential/2.0/credential-preview",
        attributes: [
          {
            "mime-type": "text/plain",
            "name": "givenName",
            "value": "JOHN"
          },
          {
            "mime-type": "text/plain",
            "name": "familyName",
            "value": "SMITH"
          },
          {
            "mime-type": "text/plain",
            "name": "gender",
            "value": "Male"
          },
        ]
      }
    },
    linkedDataProof: {
      credential: {
        "@context": [
          "https://www.w3.org/2018/credentials/v1",
          "https://w3id.org/citizenship/v1"
        ],
        credentialSubject: {
          familyName: "SMITH",
          gender: "Male",
          givenName: "JOHN",
          type: [
            "PermanentResident",
            "Person"
          ]
        },
        description: "Government of Example Permanent Resident Card.",
        identifier: "83627465",
        issuanceDate: "2019-12-03T12:19:52Z",
        issuer: "did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th",
        name: "Permanent Resident Card",
        type: [
          "VerifiableCredential",
          "PermanentResidentCard"
        ]
      },
      options: {
        "proofType": "Ed25519Signature2018"
      }
    }
  }
})


[Popup] $(document).popup('hide all') throws error

Uncaught TypeError: Cannot read property 'defaultView' of null

$('body') works, but I feel like $(document) should work as well.

Popup functions should only be called on elements that you want to be initialized as a popup. Initializing it on document or body will most likely cause unexpected behaviors.

On a single-page app, routing to another page is a good instance where you would want to ensure all popups are hidden. How would one accomplish this other than making sure all popups have a common class?

There's a distinction between activating element (which methods are called on) and the popup. All popups share class ui popup, calling hide all on an *activating element will call internally
$(selector.popup)
  .filter(':visible')
    .transition(settings.transition)
;

which will hide all popup on page.


#61 - Correct and simplify TypeDetails#isResolved()

Addresses #61.

Have you tested this with ORM 7.0 branch?

Have you tested this with ORM 7.0 branch?

Yep, it works. It's also needed for https://github.com/hibernate/hibernate-orm/pull/8187 as I mentioned there.


Release/0.8

closing release 0.8

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (1579a81) 100.00% compared to head (1cb8ba4) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##              main      #528    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files           50        67    +17
  Lines         1119      1240   +121
  Branches       447       458    +11
==========================================
+ Hits          1119      1240   +121

Files Changed
Coverage Δ

src/abbreviate/Abbreviate.tsx
100.00% <100.00%> (ø)

src/autocomplete/Autocomplete.tsx
100.00% <100.00%> (ø)

src/autocomplete/ResultList.tsx
100.00% <100.00%> (ø)

src/blockquote/Blockquote.tsx
100.00% <100.00%> (ø)

src/breadcrumb/Breadcrumb.tsx
100.00% <100.00%> (ø)

src/breadcrumb/BreadcrumbItem.tsx
100.00% <100.00%> (ø)

src/breadcrumb/UseBreadcrumb.tsx
100.00% <100.00%> (ø)

src/button/Button.tsx
100.00% <100.00%> (ø)

src/characterCount/CharacterCount.tsx
100.00% <100.00%> (ø)

src/codesnippet/CodeSnippet.tsx
100.00% <100.00%> (ø)

... and 14 more

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


Remove getAbundanceSample and getAbundanceFeature

Do we really need those two functions? We can just call tse[1,] and tse[, "ID2"] etc. for the same.

If I remember correctly, we decided to include this to make it intuitive for people transitioning from phyloseq. tse[1,] and tse[, "ID2"] will not work. It should be https://github.com/microbiome/mia/blob/531768d893c812fc8d3e1dcbe91fdce7d2144b60/vignettes/mia.Rmd#L288
library(mia)
data("GlobalPatterns")
assay(GlobalPatterns, "counts")['522457',]
assay(GlobalPatterns, "counts")[,'CC1']

Ah true. Or also:
library(mia)
data("GlobalPatterns")
assay(GlobalPatterns['522457',], "counts")
assay(GlobalPatterns[,'CC1'], "counts")

If the only motivation to maintain the rarely used functions  getAbundanceSample and getAbundanceFeature then I am not sure if it is really critical to keep these. From maintenance perspective it would be better to get rid of these I think. Unless there is a real need. If someone gets to work with TreeSE for real I expect that they won't use these anyway?

Yes, if someone is using treeSE for some time, they will not use it. Shall I  make a PR to remove this?

Yes I would suggest so.
In principle these should be deprecated but perhaps there is no real need and could be just removed?

Pull the main branch, and then open the PR from a new branch in this repo, or from another fork.

Thanks! Looking for suggestion/opinion
I am running checks and see lot of warning for deprecated function names in the package that have not been updated in the tests section. Shall I fix these here?
package 'dplyr' was built under R version 4.2.2
Backtrace:
 1. base::library(dplyr)
      at test-10makeTreeSEFromBiom.R:8:4
 2. base (local) testRversion(pkgInfo, package, pkgpath)
── Warning ('test-10makeTreeSEFromBiom.R:10'): makeTreeSEFromBiom ──────────────
The following artifacts: '"' were cleaned from
                    rowData.
Backtrace:
 1. mia::makeTreeSEFromBiom(...)
      at test-10makeTreeSEFromBiom.R:10:4
 3. mia:::.detect_taxa_artifacts_and_clean(feature_data, clean.taxa.names)
 4. mia:::.clean_from_artifacts(x, pattern)
── Warning ('test-10makeTreeSEFromBiom.R:27'): makeTreeSEFromBiom ──────────────
The following artifacts: '"' were cleaned from
                    rowData.
Backtrace:
 1. mia::makeTreeSEFromBiom(...)
      at test-10makeTreeSEFromBiom.R:27:4
 3. mia:::.detect_taxa_artifacts_and_clean(feature_data, clean.taxa.names)
 4. mia:::.clean_from_artifacts(x, pattern)
── Warning ('test-10makeTreeSEFromBiom.R:36'): makeTreeSEFromBiom ──────────────
The following artifacts: '"' were cleaned from
                    rowData.
Backtrace:
 1. mia::makeTreeSEFromBiom(...)
      at test-10makeTreeSEFromBiom.R:36:4
 3. mia:::.detect_taxa_artifacts_and_clean(feature_data, clean.taxa.names)
 4. mia:::.clean_from_artifacts(x, pattern)
── Warning ('test-10makeTreeSEFromBiom.R:46'): makeTreeSEFromBiom ──────────────
The '\*|\?' provided at 'clean.taxa.names' were
                    not found in rowData.
Backtrace:
 1. mia::makeTreeSEFromBiom(...)
      at test-10makeTreeSEFromBiom.R:46:4
 3. mia:::.detect_taxa_artifacts_and_clean(feature_data, clean.taxa.names)
── Warning ('test-10makeTreeSEFromBiom.R:54'): makeTreeSEFromBiom ──────────────
The following artifacts: '"' were cleaned from
                    rowData.
Backtrace:
 1. mia::makeTreeSEFromBiom(...)
      at test-10makeTreeSEFromBiom.R:54:4
 3. mia:::.detect_taxa_artifacts_and_clean(feature_data, clean.taxa.names)
 4. mia:::.clean_from_artifacts(x, patterns)
── Warning ('test-10makeTreeSEFromBiom.R:70'): makeTreeSEFromBiom ──────────────
The following artifacts: '"' were cleaned from
                    rowData.
Backtrace:
 1. mia::makeTreeSEFromBiom(...)
      at test-10makeTreeSEFromBiom.R:70:4
 3. mia:::.detect_taxa_artifacts_and_clean(feature_data, clean.taxa.names)
 4. mia:::.clean_from_artifacts(x, patterns)
── Warning ('test-2merge.R:68'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(x, xr, xrl), FUN_check_x)
      at test-2merge.R:68:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:68'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(x, xr, xrl), FUN_check_x)
      at test-2merge.R:68:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:68'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(x, xr, xrl), FUN_check_x)
      at test-2merge.R:68:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:69'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(x, xr, xrl), FUN_check_x, archetype = 2)
      at test-2merge.R:69:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:69'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(x, xr, xrl), FUN_check_x, archetype = 2)
      at test-2merge.R:69:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:69'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(x, xr, xrl), FUN_check_x, archetype = 2)
      at test-2merge.R:69:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:84'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(xtse), FUN_check_x)
      at test-2merge.R:84:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. mia (local) .local(x, f, archetype, ...)
 6. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:85'): merge ─────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. base::lapply(list(xtse), FUN_check_x, archetype = 2)
      at test-2merge.R:85:4
 2. mia (local) FUN(X[[i]], ...)
 4. mia::mergeFeatures(x, f, archetype)
 5. mia (local) .local(x, f, archetype, ...)
 6. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:102'): merge ────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. mia::mergeFeatures(tse, f = rowData(tse)$group2, mergeTree = TRUE)
      at test-2merge.R:102:4
 2. mia::mergeFeatures(tse, f = rowData(tse)$group2, mergeTree = TRUE)
 3. mia (local) .local(x, f, archetype, ...)
 4. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:103'): merge ────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. mia::mergeFeatures(tse, f = rowData(tse)$group2, mergeTree = FALSE)
      at test-2merge.R:103:4
 2. mia::mergeFeatures(tse, f = rowData(tse)$group2, mergeTree = FALSE)
 3. mia (local) .local(x, f, archetype, ...)
 4. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:104'): merge ────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. mia::mergeFeatures(...)
      at test-2merge.R:104:4
 2. mia::mergeFeatures(...)
 3. mia (local) .local(x, f, archetype, ...)
 4. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:106'): merge ────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. mia::mergeFeatures(tse, f = rowData(tse)$group2, mergeTree = TRUE)
      at test-2merge.R:106:4
 2. mia::mergeFeatures(tse, f = rowData(tse)$group2, mergeTree = TRUE)
 3. mia (local) .local(x, f, archetype, ...)
 4. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:113'): merge ────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. testthat::expect_equal(...)
      at test-2merge.R:113:4
 5. mia::mergeFeatures(tse, f = rowData(tse)$group2)
 6. mia (local) .local(x, f, archetype, ...)
 7. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:116'): merge ────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. mia::mergeFeatures(tse, f = rowData(tse)$group, mergeTree = TRUE)
      at test-2merge.R:116:4
 2. mia::mergeFeatures(tse, f = rowData(tse)$group, mergeTree = TRUE)
 3. mia (local) .local(x, f, archetype, ...)
 4. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2merge.R:117'): merge ────────────────────────────────────────
'mergeRows' is deprecated.
Use 'mergeFeatures' instead.
See help("Deprecated") and help("Now mergeRows is deprecated. Use mergeFeatures instead.-deprecated").
Backtrace:
 1. mia::mergeFeatures(tse, f = rowData(tse)$group, mergeTree = FALSE)
      at test-2merge.R:117:4
 2. mia::mergeFeatures(tse, f = rowData(tse)$group, mergeTree = FALSE)
 3. mia (local) .local(x, f, archetype, ...)
 4. base::.Deprecated(old = "mergeRows", new = "mergeFeatures", "Now mergeRows is deprecated. Use mergeFeatures instead.")
── Warning ('test-2taxonomy.R:126'): taxonomy ──────────────────────────────────
package 'RSQLite' was built under R version 4.2.2
Backtrace:
 1. base::library(DECIPHER)
      at test-2taxonomy.R:126:4
 2. base::.getRequiredPackages2(pkgInfo, quietly = quietly)
 3. base::library(...)
 4. base (local) testRversion(pkgInfo, package, pkgpath)
── Warning ('test-3agglomerate.R:30'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. testthat::expect_error(...)
      at test-3agglomerate.R:30:4
 7. mia::mergeFeaturesByRank(xtse, "", na.rm = FALSE)
 8. mia (local) .local(x, ...)
 9. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:32'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. testthat::expect_error(...)
      at test-3agglomerate.R:32:4
 7. mia::mergeFeaturesByRank(xtse, "Family", na.rm = "")
 8. mia (local) .local(x, ...)
 9. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:34'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. testthat::expect_error(...)
      at test-3agglomerate.R:34:4
 7. mia::mergeFeaturesByRank(xtse, "Family", na.rm = FALSE, agglomerateTree = "")
 8. mia (local) .local(x, ...)
 9. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:38'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. testthat::expect_error(...)
      at test-3agglomerate.R:38:4
 7. mia::mergeFeaturesByRank(xtse2, "Family", na.rm = FALSE)
 8. mia (local) .local(x, ...)
 9. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:41'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(xtse, "Family", na.rm = FALSE)
      at test-3agglomerate.R:41:4
 2. mia::mergeFeaturesByRank(xtse, "Family", na.rm = FALSE)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:43'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(xtse, "Phylum", na.rm = FALSE)
      at test-3agglomerate.R:43:4
 2. mia::mergeFeaturesByRank(xtse, "Phylum", na.rm = FALSE)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:46'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(xtse, "Family", na.rm = TRUE)
      at test-3agglomerate.R:46:4
 2. mia::mergeFeaturesByRank(xtse, "Family", na.rm = TRUE)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:49'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(xtse, "Family", na.rm = FALSE)
      at test-3agglomerate.R:49:4
 2. mia::mergeFeaturesByRank(xtse, "Family", na.rm = FALSE)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:52'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(xtse, "Phylum")
      at test-3agglomerate.R:52:4
 2. mia::mergeFeaturesByRank(xtse, "Phylum")
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:55'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(xtse, "Family")
      at test-3agglomerate.R:55:4
 2. mia::mergeFeaturesByRank(xtse, "Family")
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:58'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. testthat::expect_equal(...)
      at test-3agglomerate.R:58:4
 5. mia::mergeFeaturesByRank(xtse, "Family")
 6. mia (local) .local(x, ...)
 7. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:63'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. testthat::expect_equal(...)
      at test-3agglomerate.R:63:4
 6. mia::mergeFeaturesByRank(enterotype, "Genus")
 7. mia (local) .local(x, ...)
 8. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:69'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(se, rank = "Family")
      at test-3agglomerate.R:69:4
 2. mia::mergeFeaturesByRank(se, rank = "Family")
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-3agglomerate.R:73'): agglomerate ─────────────────────────────
'agglomerateByRank' is deprecated.
Use 'mergeFeaturesByRank' instead.
See help("Deprecated") and help("Now agglomerateByRank is deprecated. Use mergeFeaturesByRank instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByRank(se, rank = "Family", mergeTree = TRUE)
      at test-3agglomerate.R:73:4
 2. mia::mergeFeaturesByRank(se, rank = "Family", mergeTree = TRUE)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-5prevalence.R:330'): mergeFeaturesByPrevalence ───────────────
'agglomerateByPrevalence' is deprecated.
Use 'mergeFeaturesByPrevalence' instead.
See help("Deprecated") and help("Now agglomerateByPrevalence is deprecated. Use mergeFeaturesByPrevalence instead.-deprecated").
Backtrace:
 1. testthat::expect_error(...)
      at test-5prevalence.R:330:4
 7. mia::mergeFeaturesByPrevalence(GlobalPatterns, other_label = TRUE)
 8. mia (local) .local(x, ...)
 9. base::.Deprecated(...)
── Warning ('test-5prevalence.R:332'): mergeFeaturesByPrevalence ───────────────
'agglomerateByPrevalence' is deprecated.
Use 'mergeFeaturesByPrevalence' instead.
See help("Deprecated") and help("Now agglomerateByPrevalence is deprecated. Use mergeFeaturesByPrevalence instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByPrevalence(GlobalPatterns)
      at test-5prevalence.R:332:4
 2. mia::mergeFeaturesByPrevalence(GlobalPatterns)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-5prevalence.R:336'): mergeFeaturesByPrevalence ───────────────
'agglomerateByPrevalence' is deprecated.
Use 'mergeFeaturesByPrevalence' instead.
See help("Deprecated") and help("Now agglomerateByPrevalence is deprecated. Use mergeFeaturesByPrevalence instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByPrevalence(...)
      at test-5prevalence.R:336:4
 2. mia::mergeFeaturesByPrevalence(...)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-5prevalence.R:346'): mergeFeaturesByPrevalence ───────────────
'agglomerateByPrevalence' is deprecated.
Use 'mergeFeaturesByPrevalence' instead.
See help("Deprecated") and help("Now agglomerateByPrevalence is deprecated. Use mergeFeaturesByPrevalence instead.-deprecated").
Backtrace:
 1. mia::mergeFeaturesByPrevalence(...)
      at test-5prevalence.R:346:4
 2. mia::mergeFeaturesByPrevalence(...)
 3. mia (local) .local(x, ...)
 4. base::.Deprecated(...)
── Warning ('test-5prevalence.R:352'): mergeFeaturesByPrevalence ───────────────
'agglomerateByPrevalence' is deprecated.
Use 'mergeFeaturesByPrevalence' instead.
See help("Deprecated") and help("Now agglomerateByPrevalence is deprecated. Use mergeFeaturesByPrevalence instead.-deprecated").
Backtrace:
 1. testthat::expect_equal(...)
      at test-5prevalence.R:352:4
 5. mia::mergeFeaturesByPrevalence(...)
 6. mia (local) .local(x, ...)
 7. base::.Deprecated(...)
── Warning ('test-5runDPCoA.R:3'): runDPCoA ────────────────────────────────────
package 'ade4' was built under R version 4.2.2
Backtrace:
 1. testthat::skip_if_not(require("ade4", quietly = TRUE))
      at test-5runDPCoA.R:3:4
 3. base::require("ade4", quietly = TRUE)
 8. base::library(...)
 9. base (local) testRversion(pkgInfo, package, pkgpath)

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure ('test-0utilites.R:96'): getAbundanceFeature/getAbundanceSample ─────
`mia:::.check_feature_sample_ids()` threw an error with unexpected message.
Expected match: "argument \"id\" is missing"
Actual message: "object '.check_feature_sample_ids' not found"
Backtrace:
    ▆
 1. └─testthat::expect_error(mia:::.check_feature_sample_ids(), "argument \"id\" is missing") at test-0utilites.R:96:4
 2.   └─testthat:::quasi_capture(...)
 3.     ├─testthat (local) .capture(...)
 4.     │ └─base::withCallingHandlers(...)
 5.     └─rlang::eval_bare(quo_get_expr(.quo), quo_get_env(.quo))
── Failure ('test-0utilites.R:98'): getAbundanceFeature/getAbundanceSample ─────
`mia:::.check_feature_sample_ids("test")` threw an error with unexpected message.
Expected match: "argument \"names\" is missing"
Actual message: "object '.check_feature_sample_ids' not found"
Backtrace:
    ▆
 1. └─testthat::expect_error(...) at test-0utilites.R:98:4
 2.   └─testthat:::quasi_capture(...)
 3.     ├─testthat (local) .capture(...)
 4.     │ └─base::withCallingHandlers(...)
 5.     └─rlang::eval_bare(quo_get_expr(.quo), quo_get_env(.quo))
── Error ('test-0utilites.R:100'): getAbundanceFeature/getAbundanceSample ──────
Error in `eval_bare(expr, quo_get_env(quo))`: object '.check_feature_sample_ids' not found
Backtrace:
    ▆
 1. └─testthat::expect_null(...) at test-0utilites.R:100:4
 2.   └─testthat::quasi_label(enquo(object), label, arg = "object")
 3.     └─rlang::eval_bare(expr, quo_get_env(quo))

[ FAIL 3 | WARN 43 | SKIP 3 | PASS 902 ]
Error: Test failures
Execution halted

Yes, that would be great! Was omitted by mistake in the recent PR I guess.

Closed via #413

This is still open, but I think this can be closed. (If not, reopen)


Fix ST2 Client for Windows Clients

We have try to rollout the st2client on the Windows 10/11 clients of our StackStorm users. But because PWD only exist on Unix Based Operation System it failed.

For the record, what's the error you're getting on Windows systems?

For the record, what's the error you're getting on Windows systems?

Based on the proposed fix os.getlogin() returns the correct information on Windows.   I don't know the context around the patch, but the workaround for getlogin was added 11/07/2017 so I question it's relevance.  I checked on the currently supported OS' and a couple of others.  They all function as expected, so I'd be inclined to use the standard os.getlogin() function to have cross-platform support provided by Python, rather than maintaining these exceptions in the StackStorm code base.
CentOS Linux 8
>>> sys.version
'3.6.8 (default, Sep 10 2021, 09:13:53) \n[GCC 8.5.0 20210514 (Red Hat 8.5.0-3)]'

>>> os.getlogin()
'root'

Ubuntu 20.04.6 LTS
>>> sys.version
'3.8.10 (default, May 26 2023, 14:05:08) \n[GCC 9.4.0]'

>>> os.getlogin()
'root'

Debian GNU/Linux 10 (buster)
>>> sys.version
'3.7.3 (default, Jun 29 2023, 18:03:57) \n[GCC 8.3.0]'

>>> os.getlogin()
'root'

Rocky Linux 9.2 (Blue Onyx)
>>> sys.version
'3.9.16 (main, May 29 2023, 00:00:00) \n[GCC 11.3.1 20221121 (Red Hat 11.3.1-4)]'

>>> os.getlogin()
'root'

Ubuntu 18.04.6 LTS
>>> sys.version
'3.6.9 (default, Mar 10 2023, 16:46:00) \n[GCC 8.4.0]'

>>> os.getlogin()
'root'

Ubuntu 22.04.3 LTS
>>> sys.version
'3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]'

>>> os.getlogin()
'root'

Hi Carlos, thank you for your Feedback.
Unfortunately, I also don't know why exactly the original fix was installed.
I can only comprehend the Problem in my Github Codespace Linux.

But I think this is a Microsoft special Linux.
Since the problem is in the supported versions, it would be better to use the integrated Python function as you said instead of having the special lock in the code.

I suspect you might be hitting this issue with your environment https://github.com/python/cpython/issues/84998.  As per the recommendation in the issue, perhaps getpass.getuser() is a more robust solution?  Does it work on windows 10/11?


Python range equivalent

Does more have any Python range equivalent, i.e. a function returning an iterable from int start until int end, exclusive?

BTW more is one of the best Dart packages out there

Thank you for the recognition.
Yes, this library has IntegerRange and DoubleRange very much in the spirit of Python.


SyntaxError in /

Error in ClashLeaders
SyntaxError in /
Unexpected token B in JSON at position 4
View on Bugsnag
Stacktrace
js/components/ClanCard.vue:52 - i.<anonymous>

View full stacktrace
Created automatically via Bugsnag

An error linked to this issue has been marked as fixed in Bugsnag
SyntaxError in /


Unable to click on links in chat window. Missing onclick call.

Is the bug present in the demo Chat SDK project? yes

What modifications have you made to the Chat SDK? small ones

Android Version: all versions have same problem

Steps taken to reproduce the problem:  send www.example.com to other user

Expected result: links be auto transfrom in clickable hyperlinks open in browser

Actual result: just text

Comments:

Fixed in 5.1.2.


SRML Democracy: Should we also only allow voting after checking that the data mapped to referendum index is valid

Please refer to the TODO in the following PR https://github.com/paritytech/substrate/pull/1172#discussion_r236973477
Currently we allow voting for a referendum index only if:

its referendum index ref_index is a key in ReferendumInfoOf.

Should we add an additional check to allow voting for a referendum index only if:

its referendum index ref_index is a key in ReferendumInfoOf, AND additionally;
the data that the ref_index is mapped to in ReferendumInfoOf is valid

For example, at the moment a voter can vote if they are voting for a referendum index ref_index that is a key in ReferendumInfoOf, even if the data that the ref_index maps to returns either:

None, OR
Some(...), where the block number, proposal, or vote threshold may somehow not have been defined or may be invalid

Perhaps a solution (if necessary) would be to add assertions in inject_referendum https://github.com/paritytech/substrate/blob/master/srml/democracy/src/lib.rs#L238 to validate that the provided arguments are valid?
Note that ReferendumInfoOf  is defined here https://github.com/paritytech/substrate/blob/master/srml/democracy/src/lib.rs#L159, as the following:
/// Information concerning any given referendum.
pub ReferendumInfoOf get(referendum_info): map ReferendumIndex => Option<(T::BlockNumber, T::Proposal, VoteThreshold)>;

if ref_index maps to None, then it is by definition not a key in ReferendumInfoOf. If it maps to Some, then we assert that it is valid, since a) it is already convention to assume storage items are valid and b) there's no way of identifying all possible invalid items.


Declaring context type on class component breaks static-property-placement

Hi,
After upgrading eslint-plugin-react from 7.31.8 to 7.31.9+ (#2581), it started breaking the declare keyword on context in TypeScript:

Not sure what is the mitigation in this case

The rule has this explicit code:
    // Flow support
    if (node.typeAnnotation && node.key.name === 'context') {
      return true;
    }

We don't seem to have tests for it, though, and I don't see this actual direct code in 54b738d24 / #1526 - @jomasti, any idea?

I ran into the same problem and started digging into the source code of lint rules for the first time. I don't understand enough yet to propose a fix but if it helps this could be a test case to reproduce it, which fails if I add it to the valid test cases of this rule:
{
  code: `
    class MyComponent extends React.Component {
      static contextTypes = {
        something: PropTypes.bool
      };
      declare context: MyContext;
    }
  `,
  features: ['ts'],
  options: [STATIC_PUBLIC_FIELD],
},

I will look around a bit more. Even if I don't find a fix it's a good learning experience!

@ljharb the snippet you mentioned is indeed identifying the context declaration as a contextTypes declaration.
From what I find it doesn't look like it's something that should be supported in Flow either (https://github.com/facebook/flow/issues/7166, https://github.com/facebook/flow/issues/2916) as it's used in conjunction with contextTypes.
Removing this check fixes the failing tests I added and doesn't break any other tests, but as you said they were just missing so there's a risk that it breaks something else.
Another possibility is checking if there is already a sibling that looks like a contextTypes declaration, but it feels weird and not robust.
    // Flow support
    if (node.typeAnnotation && node.key.name === 'context') {
      return !node.parent.body.some((sibling) => isContextTypesDeclaration(sibling));
    }

Yeah, that doesn't feel like a safe approach. You might be right that it should never have been added, and that it's safe to remove, but I'm hesitant to do that without hearing from @jomasti.

Sounds good, let’s remove it


Refactor and add view components

Add ViewComponents
Invert absolute time feature
Fix table cells
Add continue last session button
Add weekday to date format if not relative (today, yesterday, tomorrow)

The tests are mostly request specs and unit tests. And there were only small changes that concerned the system specs.


Status Bar Fixed

added "add icon" and "forward-icon" as svg so it can be responsive to both light and darkmode themes.

#The major changes are made in the androidlibrary and a fresh PR is sent already.

@wbrunette @maprehensive please check this out


Uploading duplicate Android releases do not update existing release on app distribution

Issue Description

Problem:  When building an apk and uploading it repeatedly, new releases are made every time.
When the version code and version name are unchanged, along with the contents of the build, I expect the uploaded apk to update an existing release with the same version code and version name.
Configuration

    firebase_app_distribution(
      app: "#{ENV["FIREBASE_APP_ID"]}",
      service_credentials_file: "...",  # a link to the credentials file
      apk_path: "/apk/app-dev-latest.apk",
      groups: "..." # multiple groups
    )

Complete verbose output

+------------------------+---------+------------------------+
|                       Used plugins                        |
+------------------------+---------+------------------------+
| Plugin                 | Version | Action                 |
+------------------------+---------+------------------------+
| fastlane-plugin-fireb  | 0.5.0   | firebase_app_distribu  |
| ase_app_distribution   |         | tion,                  |
|                        |         | firebase_app_distribu  |
|                        |         | tion_add_testers,      |
|                        |         | firebase_app_distribu  |
|                        |         | tion_get_latest_relea  |
|                        |         | se,                    |
|                        |         | firebase_app_distribu  |
|                        |         | tion_get_udids,        |
|                        |         | firebase_app_distribu  |
|                        |         | tion_remove_testers    |
+------------------------+---------+------------------------+

[19:00:08]: Sending anonymous analytics information
[19:00:08]: Learn more at https://docs.fastlane.tools/#metrics
[19:00:08]: No personal or sensitive data is sent.
[19:00:08]: You can disable this by adding `opt_out_usage` at the top of your Fastfile
[19:00:08]: ------------------------------
[19:00:08]: --- Step: default_platform ---
[19:00:08]: ------------------------------
[19:00:08]: Driving the lane '' 🚀
[19:00:08]: ---------------------------------------
[19:00:08]: --- Step: firebase_app_distribution ---
[19:00:08]: ---------------------------------------
[19:00:08]: Warning: Debug logging enabled. Output may include sensitive information.
[19:00:08]: 🔐 Authenticating with --service_credentials_file path parameter: {…}
[19:00:09]: ⌛ Uploading the APK.
D, [2023-04-27T19:00:09.119308 #1] DEBUG -- request: POST “link”
D, [2023-04-27T19:00:10.150202 #1] DEBUG -- response: Status 200
D, [2023-04-27T19:00:10.150314 #1] DEBUG -- response: {
  "name": "projects/{…}/apps/***/releases/-/operations/{…}"
}

D, [2023-04-27T19:00:10.151020 #1] DEBUG -- request: GET "link"
D, [2023-04-27T19:00:10.260315 #1] DEBUG -- response: Status 200
D, [2023-04-27T19:00:10.260419 #1] DEBUG -- response: {
  "name": "projects/{…}/apps/***/releases/-/operations/{…}"
}

D, [2023-04-27T19:00:15.266064 #1] DEBUG -- request: GET “link”
D, [2023-04-27T19:00:15.375655 #1] DEBUG -- response: Status 200
D, [2023-04-27T19:00:15.375751 #1] DEBUG -- response: {
  "name": "projects/{…}/apps/***/releases/-/operations/{…}"
}

D, [2023-04-27T19:00:20.381388 #1] DEBUG -- request: GET “link”
D, [2023-04-27T19:00:20.500467 #1] DEBUG -- response: Status 200
D, [2023-04-27T19:00:20.500556 #1] DEBUG -- response: {
  "name": "projects/{…}/apps/***/releases/-/operations/{…}",
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.firebase.appdistro.v1.UploadReleaseResponse",
    "result": "RELEASE_CREATED",
    "release": {
      "name": "projects/{…}/apps/***/releases/{…}",
      "displayVersion": "3.13-latest",
      "buildVersion": "233",
      "createTime": "2023-04-27T19:00:16.809979Z",
      "firebaseConsoleUri": “link”,
      "testingUri": “link”,
      "binaryDownloadUri": "link"
    }
  }
}

[19:00:20]: ✅ Uploaded APK successfully and created release 3.13-latest (233).
[19:00:20]: ⏩ No release notes passed in. Skipping this step.
D, [2023-04-27T19:00:20.502664 #1] DEBUG -- request: POST “link”
D, [2023-04-27T19:00:20.843669 #1] DEBUG -- response: Status 200
D, [2023-04-27T19:00:20.843790 #1] DEBUG -- response: {}

[19:00:20]: ✅ Added testers/groups.
[19:00:20]: 🎉 App Distribution upload finished successfully. Setting Actions.lane_context[SharedValues::FIREBASE_APP_DISTRO_RELEASE] to the uploaded release.
[19:00:20]: 🔗 View this release in the Firebase console: [“link”]
[19:00:20]: 🔗 Share this release with testers who have access: [“link”]
[19:00:20]: 🔗 Download the release binary (link expires in 1 hour): [“link”]
+------+------------------------+-------------+
|              fastlane summary               |
+------+------------------------+-------------+
| Step | Action                 | Time (in s) |
+------+------------------------+-------------+
| 1    | default_platform       | 0           |
| 2    | firebase_app_distribu  | 11          |
|      | tion                   |             |
+------+------------------------+-------------+

[19:00:20]: fastlane.tools finished successfully 🎉

Environment

Library
Version

fastlane
2.212.2

fastlane-plugin-firebase_app_distribution
0.5.0

Hi @eddiecubed !
It appears that the APKs that you are uploading are slightly different. Try comparing the output of unzip -v file.apk for your builds - especially the CRC-32.
You'll probably notice that files like classes*.dex and/or META_INF/{CERT.SF,CERT.RSA,MANIFEST.MF} differ between builds.
P.S.: If you didn't keep a copy of the APKs you can download them from the Firebase console.

FYI: Stackoverflow has some information about reproducible builds.

So a binary compare is done to determine uniqueness for releases?
Thank you for the timely response.

So a binary compare is done to determine uniqueness for releases?

We're actually comparing a fingerprint of the CRC-32 checksums.

Same thing happening for me, iOS is working fine


SQL Projects template shows the old Microsoft.Build.Sql verison instead of the latest preview

Azure Data Studio Version: 1.49
OS Version: Any

Steps to Reproduce:

Creating a new project in SQL project extension 1.4.3
Verify the SDK version is 0.1.12-preview, instead of 0.2.0-preview

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

I think we need to update the extension to pull from SqlProjects instead of the templates file


Certain currently non-waterloggable non-full blocks should be made waterloggable

This includes farmland, grass paths, pistons, piston heads, and shulker boxes. Leaves may also be included.

Farmland and paths are only one pixel lower than a full block. When waterlogged, the water level isn't high enough to show up.
When Pistons move blocks, the fluid they contain is removed, so waterlogging them to have the water removed when they move doesn't seem too useful.
I'll still look into adding configs for these, though I'll likely have them off by default.

The issue with farmland and grass paths becomes a bit more clear when the blocks are placed underwater, since water occupies a full cube at lower depths.

Configs for this have been added as of 1.8.0.


Wormhole size Indicator with more options

Rn you can only select if its a frigate hole or not, but in reality there are more types than that.
This is what the right click menu in pathfinder looks like for this, just as a reference:

When this is implemented, subissue 3 from #16 can also be made.

Connections between systems get updated based on type of wormhole, like a X877 is always L sized, so the connection that it makes to another system is marked as L sized automatically


Add protocol parameter which exposes the reward retention period

Rewards are kept for a limited amount of epochs. To make it transparent to API consumers how long that is, we should add a protocol parameter which exposes the RewardsRetentionPeriod (name proposal).

This protocol parameter does not necessarily have to be the one used in pruning, but at the least used in calculating the rewards. That is, only rewards up until the retention period should be retrieved. Whether more are stored that could be pruned is not as important.


Upgrade ssl context to sslv3

tlsv12 causes issues with validating certificates on some idP servers with valid ssl certs, upgrading to sslv3 fixes these issues.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: AndrewBabbitt97
To complete the pull request process, please assign sawlanipradeep
You can assign the PR to them by writing /assign @sawlanipradeep in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@googlebot I signed it!

@googlebot I signed it!

@googlebot I signed it!

Disregard the change, however of note is that it looks like the version of debian your last release was built with has an issue with some ssl certs, found the reason my change worked wasnt the code change but by building the image using a newer version of the debian image.


Allow slicing the PartialPipeline

Normal sklearn pipelines allow getting out sub-pipelines by using the sequence slicing notation. I use this frequently to check and debug the data right before it goes into the model. This doesn't work for PartialPipeline because some arguments are missing in the constructor.
This PR currently only contains a test case illustrating the behaviour. Do you want to support slicing for partial pipelines as well? Then I'll update the PR with the required changes.

The slicing feels like a solid trick. Especially when you consider that the alternative might be a PartialDebugPipeline 😅 .

Right, that was a simple fix. Getting rid of the __init__ that did nothing else than call super fixes it

I just also allowed to slice the feature union here. Pushed a new version to pypi too.


Migrate to Cytoscape ^3.0.0

Can this extension be ported to Cytoscape ^3.0.0 easily (no breaking-changes)?

This extension has been tested to work fine with latest public release of Cytoscape.js version 3.1

@metincansiper Could you publish it to npm? https://www.npmjs.com/package/cytoscape-autopan-on-drag

@anault done


[Question] Replace language model

Question
I would like to change the language model from llama to baihuan-13B.
I update code in LLaVA/lava/model/language_ Model/llava_ Llama.py, such as replacing LlamaModel with AutoModel, but received the following error
ValueError: Unrecognized configuration class<class' transformers_ Modules XXXX. configuration_ Baichuan BaihuanConfig '>for this kind of AutoModel: LlavaLlamaForCausalLM
How should I correct this error？
Thank you.

How about using BaichuanModel with the following code?
https://huggingface.co/baichuan-inc/Baichuan-13B-Base/blob/main/modeling_baichuan.py


Add immutable map accessors to OccupiedEntry and VacantEntry

Without these, it is not possible to inspect other keys in the map while deciding how to process the entry, forcing the user to either perform unnecessary work before calling entry or performing multiple map lookups for the entry key.
For example:
fn some_expensive_operation(...) -> bool { ... }

let mut map: HashMap<K, V> = ...;

// old way, with two lookups for `key`
if !map.contains_key(key) && some_expensive_operation(map.get(other_key)) {
    map.insert(key, val);
}

// old way, with expensive operation done unnecessarily when `key` is
// already present
if some_expensive_operation(map.get(other_key)) {
    if let VacantEntry(e) = map.entry(key) {
        e.insert(val);
    }
}

// new way, with one lookup for `key`
if let VacantEntry(e) = map.entry(key) {
  if some_expensive_operation(e.map().get(other_key)) {
    e.insert(val);
  }
}

We do not provide accessors returning a mutable reference to the map because doing so would make it possible to invalidate the entry itself.

This feels sound and reasonable to add, but I'll defer to others on whether that's actually the case.

Maybe an entry form of get_many_mut might help.

That would be fine too.

I would be interested in some more specifics on why you're looking to do this

While deciding whether to insert a new entry into a map, I need to do as many as four other lookups, each accompanied by some additional, potentially expensive processing on the corresponding values, if they are present at all. Right now I just do two lookups for the to-be-inserted key (contains_key followed by insert) rather than using the entry API due to the inability to access the map (immutably in this case) while an entry is outstanding.

I guess that my confusion lies in why you specifically need the different things being checked to all exist within the map as separate entries, rather than all lumped together in a single entry, if you want to access them all at once.

Could these be renamed to hash_map to avoid confusion with the very commonly used map method?
Also I can see a use case for into_hash_map which discards the entry and returns the original mutable reference that the entry was constructed from.

Maybe an entry form of get_many_mut might help.

That won't work since an invariant of the entry API is that only one entry may exist at any time. Otherwise methods on one entry would invalidate the others.

Also could you add these to:

Entry, EntryRef, VacantEntryRef
The entry types for HashSet and HashTable.

The entry types for HashSet and HashTable.

Is it possible to do this for HashSet without unsafe? hash_set::OccupiedEntry has a reference to hash_map::OccupiedEntry, but HashSet isn't just a type alias for HashMap.

Actually the API as it is will certainly cause problems in the future when we want to rewrite HashMap on top of HashTable for the same reason we can't support HashSet directly: HashTable's ExtractIf can only provide a reference to the HashTable.
Perhaps the API could be re-considered: instead of a returning a reference the the map, there could be a method which explicitly performs a lookup.

Perhaps the API could be re-considered: instead of a returning a reference the the map, there could be a method which explicitly performs a lookup.

This makes sense, though it's unfortunate that each method of interest would have to be explicitly exposed here. I will update this PR with that approach shortly, exposing only get for now.


Intellisense stops working occasionally

Actual Behavior
Intellisense stops working occasionally. When it stoped, even if I restarted my computer it didn't work, when I disabled and enabled the extension, it started to work somehow.
Logs
OmniSharp log
Post the output from Output-->OmniSharp log here
C# log
Post the output from Output-->C# here
Environment information
VSCode version: 1.33.1
C# Extension: 1.19.1
Mono Information
        OmniSharp using global mono :5.20.1
Dotnet Information
.NET Core SDK (reflecting any global.json):
 Version:   2.2.106
 Commit:    aa79b139a8
Runtime Environment:
OS Name:     Mac OS X
OS Version:  10.14
OS Platform: Darwin
RID:         osx.10.14-x64
Base Path:   /usr/local/share/dotnet/sdk/2.2.106/
Host (useful for support):
Version: 2.2.4
Commit:  f95848e524
.NET Core SDKs installed:
2.2.106 [/usr/local/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension
Author
Version

auto-close-tag
formulahendry
0.5.6

auto-rename-tag
formulahendry
0.1.0

beautify
HookyQR
1.5.0

cpptools
ms-vscode
0.23.1

csharp
ms-vscode
1.19.1

gitlens
eamodio
9.8.2

JavaScriptSnippets
xabikos
1.7.2

mssql
ms-mssql
1.6.0

vetur
octref
0.21.0

vscode-docker
PeterJausovec
0.6.2

vscode-eslint
dbaeumer
1.9.0

vscode-peacock
johnpapa
2.3.0

vscode-trello-viewer
Ho-Wan
0.6.0

I have mac and following worked for me
VS Code Settings.
omnisharp.useGlobalMono = never

There have been lots of improvements since this issue was opened. Please open a new issue with logs if you are still running into this.


Update the NPM package

Hi, the interpret version dependence was updated on package.json to load the new coffee transpiler. It will be nice to get it working on the knex package from NPM.

already fixed in master

Hi elhigu, i'm new here on knex, what is the rule (or politics) to update the NPM package?

in case if there is major version change, one should check more carefully if the new version is compatible... but mostly just send update PR and if tests pass it should be fine.


[ldd-msss_cam_mh] Change top-level class name

The top level class name is "Surface_Mission_Information".... doh!  Cut-and-paste disease.  It should be "MSSS_Camera_Mini_Header".
Also a number of xs:element entries are needed in img: so we can find the cross-dictionary elements.
Much as I hate to say it, in img:, Companding is a child of Sampling.  So we should do the same here... refer to img:Sampling rather than img:Companding (although likely it'll be nothing but an img:Companding child inside img:Sampling).

@thareUSGS also please include the new img:Optical_Properties as a child in the MSSS dictionary (which also means exposing it as a xs:element in img as well)

Also a number of xs:element entries are needed in img: so we can find the cross-dictionary elements.

I don't know what this means. Do we need to do anything here for MSSS_Camera_Mini_Header

@thareUSGS well if the cross-dictionary use gets approved, then all that's needed in this dictionary is to refer to the img: items (which I think is already in place).  It's really a to-do for the img: dictionary to add the xs:element entries that allow cross-dictionary usage.
The list is:
img:Sampling
img:Detector
img:Exposure
img:Focus
img:Onboard_Compression
img:Optical_Filter
img:Subframe
img:Instrument_State
Note that img:Companding is not needed because img:Sampling is on the list.  Once a top level item is there, it apparently makes all children available too (at least given the geom coord reference example).

I get it. Yes those were updated to use IMG and just pulled in via https://github.com/pds-data-dictionaries/ldd-msss_cam_mh/pull/10


Remove arrays of scaling factors

Alternative to https://github.com/JuliaMath/AbstractFFTs.jl/pull/114 that avoids the computation of the array of scaling factors completely.
Tested locally with regular arrays and static arrays. Using broadcast instead of map (potentially including d etc. as broadcasted arguments) would return SizedArrays instead of StaticArrays for SArray inputs, hence I went with map instead.
Has to be tested with Zygote and CUDA as well (for the latter it might be useful to set up GPU tests with buildkite and for the former downstream tests with Zygote, limited to FFTs, would be useful).
Edit: Tests of Zygote#master pass locally with this PR.

What do you think of adding a couple tests of view inputs? E.g. see #117 (made a PR to this branch rather than a code suggestion since I cannot code suggest on unchanged files).

Bump on merge?

Can we get a release, mainly in order to include this PR and fix Zygote tests? (https://github.com/FluxML/Zygote.jl/pull/1452)

I think there are some problems with #113 which is included in the master branch. Would be good to fix those first, or revert #113, before tagging a new release.

Were the problems introduced by #113 addressed by #123? If not, what are the additional issues that need fixing?


deploying machine causes hostname change on proxmox host

Hi i've got a strange problem whereby i can't find the underlying problem
If i deploy a VM with terraform and reboot my proxmox node, the proxmox node wil get automatically the hostname of the vm. This causes the proxmox node to not start it services. Also in the /etc/hosts it will have this rule: <IP_ADDRESS> kube01.<my_domain> kube01
In the header of /etc/hosts it has the following info:
# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
#     /etc/cloud/cloud.cfg or cloud-config from user-data

Nowhere has been set the 'manage_etc_hosts' variable as True also changing it to false in the /etc/cloud/cloud.cfg doesn't solve the problem. Only after i changed the /etc/cloud/templates/hosts.debian.tmpl with my hardcoded proxmox name and ip it solves the problem
After this and changing my hostname back to the original (after a reboot) everything works as before.
This is my terraform code that i am using:
# Proxmox Full-Clone
# ---
# Create a new VM from a clone

resource "proxmox_vm_qemu" "vm1" {

  # VM General Settings
  target_node = "proxmox"
  vmid        = "121"
  name        = "kube01"
  desc        = "kube01"

  # VM Advanced General Settings
  onboot = true

  # VM OS Settings
  clone = "ubuntu-22.04-server-cloudimg-amd64-template"

  # VM System Settings
  agent = 1

  # VM CPU Settings
  cores   = 2
  sockets = 1
  cpu     = "host"

  # VM Memory Settings
  memory = 4096

  searchdomain = "<my_domain>"
  # VM Network Settings
  network {
    bridge = "vmbr0"
    model  = "virtio"
  }

  # VM Cloud-Init Settings
  os_type = "cloud-init"

  # (Optional) IP Address and Gateway
  # ipconfig0 = "ip=<IP_ADDRESS>/0,gw=<IP_ADDRESS>"

  # (Optional) Default User
  # ciuser = "your-username"

  # (Optional) Add your SSH KEY
  sshkeys =  <my_ssh_public_key>

  lifecycle {
    ignore_changes = [
      nameserver,
      ssh_host,
      network,
      disk,
      ssh_port,
      qemu_os,
      ipconfig0,
      network,
      disk_gb,
    ]
  }
}

fixed the problem. I installed the cloud-init package on the Proxmox host itself which causes those problems. After i removed the package with apt purge cloud-init -y everything works as intented


P12/PEM file support

OS: macOS 10.14.6
Node.js version: 12.6.0
npm version: 6.9.0
google-auth-library version: 5.4.0

I'm struggling to get a client using a P12/PEM file, and I'm wondering if it's my fault!
const GoogleAuth = require('google-auth-library').GoogleAuth
const auth = new GoogleAuth({ keyFilename: '/path/to/key.p12' })
await auth.getClient() // crashes with below output

 SyntaxError: Unexpected token � in JSON at position 1
    at JSON.parse (<anonymous>)
    at ReadStream.<anonymous> (/Users/stephen/dev/play/gissue-218/node_modules/google-auth-library/build/src/auth/googleauth.js:347:39)
    at ReadStream.emit (events.js:208:15)
    at ReadStream.EventEmitter.emit (domain.js:494:23)
    at endReadableNT (_stream_readable.js:1154:12)
    at processTicksAndRejections (internal/process/task_queues.js:77:11)

The key file is being passed around the "googleauth.js" file, and after a read stream is opened to digest the key file, it is parsed as JSON, which throws the error. The JWT file handles a key file path by checking the mime-type.
Does it look like I'm doing something wrong here?

Any news on this? @JustinBeckwith
I've the same issue.
Thanks!

Nope

@bcoe @JustinBeckwith do we support this form of auth anymore? Did we lose it one day and nobody noticed?

I honestly have no idea :/  I know the auth library supports it on some level

@stephenplusplus we support self-signed JWTs, is that what we'd expect this key file to be used for?

@bcoe java sdk supports P12/PEM file formats, it looks there like
new GoogleCredential.Builder().setTransport(transport)         .setJsonFactory(jsonFactory)         .setServiceAccountId(serviceAccountId)         .setServiceAccountScopes(serviceAccountScopes)         .setServiceAccountPrivateKeyFromP12File(p12File)         .build();
We are trying to migrate our code to nodejs, but not able to run api requests through service account as we use p12 file

@bcoe java sdk supports P12/PEM file formats, it looks there like
new GoogleCredential.Builder().setTransport(transport)         .setJsonFactory(jsonFactory)         .setServiceAccountId(serviceAccountId)         .setServiceAccountScopes(serviceAccountScopes)         .setServiceAccountPrivateKeyFromP12File(p12File)         .build();
We are trying to migrate our code to nodejs, but not able to run api requests through service account as we use p12 file

@aareshchanka we have several tests related to authenticating a client with a PEM or P12 format certificate:
https://github.com/googleapis/google-auth-library-nodejs/blob/9116f247486d6376feca505bbfa42a91d5e579e2/test/test.jwt.ts#L114
Do you run into an error if you use these as an example.

@aareshchanka we have several tests related to authenticating a client with a PEM or P12 format certificate:
https://github.com/googleapis/google-auth-library-nodejs/blob/9116f247486d6376feca505bbfa42a91d5e579e2/test/test.jwt.ts#L114
Do you run into an error if you use these as an example.


Alerts management contains operator support for resource type condition

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

Alerts management


Server does not seem to support keep-alive and runs out of file descriptors

Describe the bug
oxigraph_server 0.3.22 does not seem to support HTTP Keep-Alive according to its response headers, and so under a relatively high query load, things break with the following error:
OxHTTP TCP error when opening stream: Too many open files (os error 24)

There's of course only so many queries that can be run concurrently, but by not having Keep-Alive it will increase the amount of simultaneously-open connections for the same amount of concurrent queries, and also increase connection management overhead, so adding Keep-Alive would presumably make it less likely that this issue occurs.
To Reproduce
Steps to reproduce the behavior:

Run oxigraph_server version 0.3.22
As far as I can tell, this is getting triggered by my application running a lot of concurrent(-ish) queries. They're not exactly concurrent, but fast enough that the connections pile up faster than they can be finished. I don't think it's related to the specific query.

Thank you for using Oxigraph and writing this bug report! oxigraph_server 0.3.22 should support HTTP Keep-Alive but it's possible that the implementation is buggy (Oxigraph uses its own http server implementation called oxhttp and I have not carefully tested keep-alive support). Are you sure keep-alive is not working?

An aside:

but by not having Keep-Alive it will increase the amount of simultaneously-open connections for the same amount of concurrent queries

I am not sure this is true. Indeed, keep-alive only allows to reuse an existing connection for a subsequent request, not having multiple requests running at the same time on the same connection (we would need HTTP2 multiplexing for that). Without keep-alive, connections are closed as soon as the response is send whereas with keep-alive they might stay open for possible subsequent requests. Hence, the number of simultaneously-open connections might be higher with keep-alive.

Indeed, keep-alive only allows to reuse an existing connection for a subsequent request, not having multiple requests running at the same time on the same connection (we would need HTTP2 multiplexing for that).

Note that HTTP/1.1 does support having multiple requests in flight on a single connection via pipelining, but it was never widely implemented and still suffers from head-of-line blocking as response order matches request order.

Are you sure keep-alive is not working?

I've tried to determine this by looking at the headers that are sent and received (as that was the easiest thing to inspect at the time), and while the browser sent a Connection: keep-alive header, neither that header nor a detailed Keep-Alive header were returned:

It's possible that I checked that wrong, of course - if you can suggest a better way to verify this, please let me know!

An aside:

but by not having Keep-Alive it will increase the amount of simultaneously-open connections for the same amount of concurrent queries

I am not sure this is true. Indeed, keep-alive only allows to reuse an existing connection for a subsequent request, not having multiple requests running at the same time on the same connection (we would need HTTP2 multiplexing for that). So, with or without keep-alive we need as many connections as concurrent queries. More, without keep-alive, connections are closed as soon as the response is send whereas with keep-alive they might stay open for possible subsequent requests. Hence, the number of simultaneously-open connections might be higher with keep-alive.

Right. To clarify: my reasoning was that there is a (brief but nonzero) period of time after a request has been processed and a response has been sent, during which the connection can no longer be used for another request (due to keepalive being disabled), but it still occupies a file descriptor because it has not been fully closed yet. That would not normally be an issue, but in the case of a high request volume, it would reduce the total amount of concurrent requests because a nonzero percentage of the sockets is open-but-not-usable (versus about 100% being usable in a keep-alive scenario).
Regarding the number of simultaneously open connections being higher with keep-alive: I'm not sure how that would happen? It would make sense that connections linger for longer, but in a high-request-rate scenario where you're running up against the FD limit, there is a subset of requests that would be scheduled on a just-freed-up connection that would otherwise (with keep-alive disabled) have spawned a new connection while the just-completed connection might still be closing - as far as I can tell, that should lead to a lower connection count.
(All of this is just about stretching up the margins, of course, one-concurrent-query-per-connection is fundamentally going to be limiting.)

we would need HTTP2 multiplexing for that

Are there any plans to implement support for this in the future? For my project I intend to eventually switch to Neon/Rust bindings (hopefully before this becomes a problem outside of stresstest scenarios), but I imagine that that may not be an option for everyone, and other users may run into the same issue in the future.

I've tried to determine this by looking at the headers that are sent and received (as that was the easiest thing to inspect at the time), and while the browser sent a Connection: keep-alive header, neither that header nor a detailed Keep-Alive header were returned:

The tricky thing here is that connection: keep-alive is the default in HTTP 1.1. It's why OxHTTP is not returning it.
curl seems to properly reuse requests. curl -v http://localhost:7878 -o /dev/null http://localhost:7878 -o /dev/null properly prints "Re-using existing connection with host localhost"

Regarding the number of simultaneously open connections being higher with keep-alive: I'm not sure how that would happen? It would make sense that connections linger for longer, but in a high-request-rate scenario where you're running up against the FD limit, there is a subset of requests that would be scheduled on a just-freed-up connection that would otherwise (with keep-alive disabled) have spawned a new connection while the just-completed connection might still be closing - as far as I can tell, that should lead to a lower connection count.

Yes! In the high request rate from the same host senario, indeed, it should not affect much.

we would need HTTP2 multiplexing for that
Are there any plans to implement support for this in the future? For my project I intend to eventually switch to Neon/Rust bindings (hopefully before this becomes a problem outside of stresstest scenarios), but I imagine that that may not be an option for everyone, and other users may run into the same issue in the future.

Nothing for now. It would be a big task to get done. Imho there are a lot of lower hanging fruits to grab eg. around making query optimizer and evaluation way better that would make also a good impact on the supported workload.


Mak/update polkadot api

Fix #139

I'll exempt my review here since I'm not familiar with how those dependencies work due to unfamiliarity with the project


[WIP] OSF addon for Microsoft OneDrive

Initial Work In Progress PR for Microsoft OneDrive OSF addon
Notes
We copied Box as the starting point for this addon. There are debug and info logging statements that we'll remove before the final PR.
Also see the corresponding PR for WaterButler.
Limitations

This only works with OneDrive for personal use. OneDrive for business has a different authentication endpoints and the API is slightlightly different at this time. Additionally, Microsoft has released graph which, I believe, should (when it is complete) unify OneDrive for Personal and OneDrive for Business under one API. The OneDrive API used here should be compatible with Graph based on the documentation I've seen.
OneDrive's API only returns the most recent revision for an item (file or folder). I don't believe there is a way around this now.

Issues under development

Delete Folder
Download Zip
Rename File
Rename Folder
Copy Folder
Copy File

Functionality in Place (i.e. "dev complete")

Upload files
Create folders
Download Files
Delete files
View Revisions
List Files/Folders in a folder

Screenshots

Note: I don't have MFR running.  I'm having issues getting it running in ubuntu.

@samchrisinger ... when you get a window of time ... @caseyrygt is ready for some feedback on this add-on PR. Thanks!

I'm not an addon expert by any means, so I don't know if this is the right way to solve this, but I couldn't connect my account until I uncommented the auth attribute in the return value of addon_serialized_urls() in serializer.py.

@caseyrygt I'm done with a first pass here. Please take a look at the comments.
It would be good to have the Travis build passing (looks like both flake8 errors and test failures) before the next pass.
Probably the next step is to finish addressing comments on the WaterButler PR, then I'll do a full functional review and another pass of CR.

@samchrisinger, thanks for the feedback.  I'll get things cleaned up and submit another PR along with the cleanup of the WB code.
Happy holidays!

Hey @caseyrygt,
I'm just getting back to review for the WB-side of this PR.  The OSF-side addon is working for me, but I get a lot of flake8 errors for this branch.  Could you fix those up?  Travis requires a passing flake check.
Also, I'm assuming https://github.com/caseyrygt/waterbutler/tree/feature/onedrive-provider-35 is the correct WB-side branch to review?  If so, could you re-open a PR for me to leave comments on?  Thank you!
Cheers,
@felliott

Hi Fitz,
You're correct, onedrive-provider-35 is the correct (python 3.5) branch to
review.
I'll submit a new PR and fix the flake8 errors in OSF.
Thanks!
On Wed, Apr 27, 2016 at 2:43 PM, Fitz Elliott<EMAIL_ADDRESS>wrote:

Hey @caseyrygt https://github.com/caseyrygt,
I'm just getting back to review for the WB-side of this PR. The OSF-side
addon is working for me, but I get a lot of flake8 errors for this branch.
Could you fix those up? Travis requires a passing flake check.
Also, I'm assuming
https://github.com/caseyrygt/waterbutler/tree/feature/onedrive-provider-35
is the correct WB-side branch to review? If so, could you re-open a PR for
me to leave comments on? Thank you!
Cheers,
@felliott https://github.com/felliott
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/CenterForOpenScience/osf.io/pull/4681#issuecomment-215188828

--
Ryan Casey
CEO
http://www.growingtechnologies.com/
growingtechnologies.com
<EMAIL_ADDRESS>Direct:<PHONE_NUMBER>
For Technical Support:<PHONE_NUMBER> option 2 /
<EMAIL_ADDRESS>

@samchrisinger & @felliott:  Sorry for the delay on this.  I think I have resolved all of the issues / items you had.  Could you please review this?
Thanks!

@samchrisinger: I meat to ask you about an error I'm getting in the test_views tests:
BuildError: ('JSONRenderer__onedrive_folder_list', {}, None)
It happens whenever I call api_url_for (e.g. url = api_url_for('onedrive_folder_list')).
In looking at the dropbox test_views, it calls: self.project.api_url_for.  Unfortunately, when I call that method I get: AttributeError: 'TestAuthViews' object has no attribute 'project'
I'm guessing that between when I'd copied the tests from dropbox to now, some other changes were made to OSF's testing or "base" framework.
Could you give me any points for resolving this?
Thanks.

@caseyrygt some of these are happening because the route just doesn't exist: https://github.com/CenterForOpenScience/osf.io/pull/4681/files#diff-0ee0e60ebe1815cd3f65f833c2e4976aR35
(here you need api_url_for('oauth_connect', service_name='onedrive')-- see https://github.com/CenterForOpenScience/osf.io/blob/develop/website/routes.py#L354)
I can't find an example test case using 'onedrive_folder_list', but all of the urls you try to look up need to exist in your onedrive/routes.py.

Pausing review here for the night, picking up at the serializer in the AM.

Trivial, but all the console logging will need to go before this gets merged.

Somewhat light first pass complete. 🐧
I'll review in more depth and do functional testing when the above comments have been addressed. I know updating the views and tests to the new paradigm seems like a lot of work, but there's a good chance it'll be simpler for both of us than fixing and verifying the correctness of all the commented-out tests that presumably need some amount of maintenance.
If you have any questions or need any clarifications, feel free to @ mention me, or if you're on Slack I can hop on and discuss things with you there.
Back to you, @caseyrygt


KYLIN-4618 Upgrade kylin docker image for kylin 3.1.0

Upgrade kylin docker image for kylin 3.1.0
Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to Kylin?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I have create an issue on Kylin's jira, and have described the bug/feature there in detail
[ ] Commit messages in my PR start with the related jira ID, like "KYLIN-0000 Make Kylin project open-source"
[ ] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If this change need a document change, I will prepare another pr against the document branch
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at user@kylin or dev@kylin by explaining why you chose the solution you did and what alternatives you considered, etc...

Pull Request Test Coverage Report for Build 6097

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.008%) to 27.982%

Files with Coverage Reduction
New Missed Lines
%

stream-core/src/main/java/org/apache/kylin/stream/core/storage/columnar/ColumnarStoreCache.java
1
56.82%

core-cube/src/main/java/org/apache/kylin/cube/inmemcubing/MemDiskStore.java
4
78.12%

Totals

Change from base Build 6065:
0.008%

Covered Lines:
26116

Relevant Lines:
93331

💛  - Coveralls

LGTM


Fix resume issues [JENKINS-49686] and [JENKINS-50199] and [JENKINS-50407]

Aims to resolve (in conjunction with workflow-cps changes as well that help harden the logic):

JENKINS-50199
JENKINS-49686
JENKINS-50407

Includes lazy-load for FlowExecutions (enhancement):  JENKINS-45585 -- which if merged will replace 49086 because it will defer a ton of the load-time logic for completed Pipelines.
TODOs:

Cross-test with workflow-cps durability tests
Fix issue with unitialized listener field for unable-to-resume flows (may mandate changes in wf-cps too)
Hardening: consider forcing atomic write of XML file when re-saving with the completed field persisted -- even when normally non-atomic (guarantees we won't mangle original build record if an error occurs upon save).

Merging now that I've done one more round of integration testing locally using the related workflow-cps PR and an updated snapshot.