Break up timepicker's model into separate values

This change is to break up the model into separate values, i.e. hours, minutes, and seconds. This is to fix date related issues for a component that shouldn't rely on date objects at all.

@wesleycho since I'm looking into timepicker in the context of https://github.com/ng-bootstrap/ng-bootstrap I would like to brainstorm here.
I totally agree that using Date object is sub-optimal and we should use another data structure instead. What is your current thinking regarding the exact data structure? For me it could one of:

string (possibly with a configurable parsing / formatting strategy)
A predefined data structure (ex. {hour: 12, minute: 15: second: 00})
any arbitrary data structure where a user is obliged to provide parsing / formatting utility

At the end of the day we want sth like: <input ng-model="timeExp" bs-timepicker> and we need to define:

allowed values for timeExp
how to turn value of timeExp to a string (we need it so we can display a selected time in the input field)

Thought?

I'm a fan of using an object (second option), that way it is a nice & expected structure, and simple enough for a user to work with (i.e. modifying a date object with the time values to submit to a server).
Allowed values - we should validate that the object is explicitly as we expect (predefined data structure).
Converting to string - given predefined structure, would be very easy to convert to string for each input using a leftPad function.

I'm a fan of using an object (second option), that way it is a nice & expected structure, and simple enough for a user to work with

I agree. Let's start with this. We could always add more formats as we go.

I too agree we could use the object. I think it is more flexible.

specific Issues (individually closed) to address in rewrite:

[ ] form validation
[ ] manually clearing fields
[ ] when min/max is used
[ ] ng-required support
[ ] support 0 values
[ ] investigate supporting dynamic values for min and max
[ ] when used in modal
[ ] ng-model-options support
[ ] do not use Date as model object (store fields separately)
[ ] investigate use from within input-group-btn (may be CSS issue on user side)

I am looking to rewrite my time tracking utility with ng. At the moment I have time and date tied together so when you push time back beyond 'zero' date will update accordingly to day before. In other words script will update date values if you're pushing time over date boundaries.
For me it is very useful to have this two tied together (time and date) because I think this is more natural behavior for this type of objects.
I don't have a plunker here but you can try this on my demo 'Add Time Entry' button.

@alcalbg this is something you would best manage yourself and it's not that hard.  Using the same Date object for both the date and time picker is fraught with gotchas and corner cases which is why we do not support it.

I do second the notion of using an object for the input per my thumbs-up above. I will suggest, though, that the object should continue to use a defined subset of JS Date standard getters & setters instead of direct member access, so that a Date object or Date object proxy can be easily used. Or, introduce your own proxy object interface with a pre-built wrapper for Date. Date certainly has its problems, but it still handles a lot of bad cases for us that I don't want to have to deal with.

Is there any eta? This bug is making me trouble 6088

Any status on this? Relying on the Date object is definitely suboptimal.


The Requirements.txt does not have all the module's [BUG]

Describe the bug
Can't run main.py asking for no module, after installing the reqirements.txt this same error
Device
Type: Computer
OS: Windows
Browser: Chrome
Additional context
Pls update the requirements.txt or list the needed modules

Updated requirements.txt in #168


Prisma scripts cannot find the prisma executable

Describe the bug
Prisma scripts cannot find the prisma executable.  npm run new_service fails with a E_NOENT error when trying to execute prisma deploy. Same for npm run deploy.
To Reproduce
Steps to reproduce the behavior:

Follow the install guide up to step 6

Expected behavior
Step 6 runs successfully.
Additional context

Environment: OS is Windows 10, but bug was also reproduced on Windows 7. prisma is not installed globally, but is installed locally (server/node_modules/.bin/prisma is present)
Workaround: open server/scripts/prisma_new_service/index.js and replace "prisma deploy" by "<absolute path to FAQ>\\server\\node_modules\\.bin\\prisma.cmd deploy"
Same problem and workaround with npm run deploy

This bug is caused by this: https://nodejs.org/dist/latest-v10.x/docs/api/child_process.html#child_process_spawning_bat_and_cmd_files_on_windows
I've confirmed it's a simple question of using execSync instead of execFileSync. I need to test the new code on Linux too.

I need to test the new code on Linux too.

Works. PR incoming.


Access to data

Hi - I am a researcher with the University of North Carolina Charlotte and I am very interested in downloading your Healthcare Twitter Analysis data. However, when trying to download from S3, I get the following error:
<Error>
InvalidObjectState
<Message>
The operation is not valid for the object's storage class
</Message>
<RequestId>A4CD9EACE8648B04</RequestId>
<HostId>
9UGyZQL1SmgFaWwvXs4oRHBlJKY/e9peN5LzFrPMQyQBp+RoBaGX+NfuBbB87tIlE4eJcVfo1Xk=
</HostId>
</Error>

Are these data still available? I am happy to pay the AWS transfer fee to access the data.

I have the same issue, no access to data @grfiv


Feature: Support single-line comments in the CLI with syntax highlighting

Kùzu version
0.5.0
What operating system are you using?
macOS
What happened?
Currently, single line comments aren't parsed by the CLI:
kuzu> // This is a comment
..> match (n) return n.name;
Error: Parser exception: mismatched input '<EOF>' expecting {ALTER, ATTACH, BEGIN, CALL, CHECKPOINT, COMMENT, COMMIT, COPY, CREATE, DELETE, DETACH, DROP, EXPORT, IMPORT, INSTALL, LOAD, MATCH, MERGE, OPTIONAL, PROJECT, RETURN, ROLLBACK, SET, UNWIND, USE, WITH} (line: 1, offset: 44)
"// This is a comment match (n) return n.name"

Multi-line comments work.
kuzu> /* This
..> is a comment */
..> match (n:Person) return n.*;
┌────────┐
│ n.name │
│ STRING │
├────────┤
│ Alice  │
│ Bob    │
│ Carol  │
│ Dan    │
└────────┘
(4 tuples)
(1 column)
Time: 0.09ms (compiling), 0.25ms (executing)

No issues in other clients
Kùzu Explorer has no issues and parses the single line comment correctly, presumably because it uses the Node.js client under the hood. The Python client also parses both kinds of comments correctly.
Desired behaviour
The user should be able to specify single line comments in the CLI that span an entire line, just like they do in the other interfaces to Kùzu.
A simple rule could be "if line starts with // parse that entire line as a comment".
DuckDB CLI supports this
To demonstrate expected behaviour, DuckDB's CLI supports single line comments.
❯ duckdb ./ex_db.duckdb
v1.0.0 1f98600c2c
Enter ".help" for usage hints.
D -- This is a comment
D CREATE TABLE person (name STRING PRIMARY KEY);

Also, DuckDB takes care of syntax highlighting the comments in the CLI (note how it's grey in colour):

We should also add syntax highlighting in the CLI shell for comments - when something is a comment, it should be highlighted in dark grey so that it appears different from the query below.

Multi-line comments don't seem to have the proper syntax-highlighting rules in the Kùzu CLI (it seems to be highlighted like standard queries):

I think it would also be great to strip off trailing line comments, like:
kuzu> MATCH (n) // foo
..> RETURN n;
Error: Parser exception: Query must conclude with RETURN clause (line: 1, offset: 0)
"MATCH (n) // foo RETURN n"
 ^^^^^

The language clients all seem to be already doing this, so it should be the same logic, I hope.

Proper support for single line comments in the shell has been added in #4134. The improved syntax highlighting will be added in the coming weeks.

Issue was completed but never closed


Custom app installation fails with "Something went wrong" (AddAppBotToChatRosterFailed) error

Issue summary

When attempting to install a custom app into Teams, the error "Something went wrong" is presented in a modal. If we use the Teams web browser client, an HTTP 500 response with the body {errorCode: "AddAppBotToChatRosterFailed"} can be seen in the network monitor.
Given the ambiguity of the error message, it has been impossible for us to discover the actual cause of the error. There may indeed be many different possible causes.
This error does not happen consistently, and it has been impossible for us to identify the variables accounting for that inconsistency. One of our customers encounters the issue 100% of the time, others have never reported it, but our internal testing team sees it only some of the time. Sometimes app installation works, sometimes it doesn't, sometimes it works after a user logs out and back in again. We have examined every Teams and Azure security and permission setting closely and can find no obvious causes, and the installation approach described below worked fine for us for a long while but has been having this problem relatively recently.

Requested remediation

This is an urgent, blocking problem for us and our customers, so any guidance that could help unblock us immediately would be greatly appreciated. Perhaps there's a hidden means of obtaining a more precise error description, or some reliable workaround steps we could take, or alternative API versions, or other such thing, that we could use while the root of this problem is being addressed. At the moment, some of our customers are entirely unable to create Teams integrations because they can't get past the last installation step and there is no useful indication of what the actual problem is.
Surface much more informative and actionable error messages through the Teams client when app installation failures occur.
Resolve any problems in Teams or Azure infrastructure and APIs that may cause such errors to occur due to factors outside of the reasonable control of the Azure tenant or Teams workspace admins.

Detailed issue description
Background
Our company's product is a tool that helps people build bot, automation, AI, and other such systems using low-code and no-code tools. We offer a MS Teams Toolkit that supports building conversation bots and interacting with the Teams API. To support our customers in getting started, we have tools that help them create the necessary configurations/manifests for Azure and Teams.
Definitions

Customer - A person who wants to use our MS Teams toolkits. That person must have access to the Azure tenant with Global Administrator permissions.
Installer - An automated process that programmatically creates the required Azure resources and generates the Teams app manifest.
Installer App - OAuth app registration in our Azure tenant that receives authorization to create new app registration and bot service in the customer's Azure tenant.
See Installer App Azure Manifest Example.
App - Azure OAuth app registration that will be created in the customer's tenant by the Installer App and bound to a Bot.
Bot - Azure bot service that will be created in the customer's tenant by the Installer App.
Access Token 1 - Access token used to create the App in the Customer's tenant.
Access Token 2 - Access token used to create the Resource Group and deploy the Bot in the Customer's tenant.
Access Token 3 - Access token used to publish and install the Bot in MS Teams.
Subscription - Azure subscription.
Resource Group - Azure resource group.
App Manifest - MS Teams app manifest JSON file. This file contains all necessary information to publish the Bot to MS Teams app catalog.
See MS Teams App Manifest Example.

Installation process

Customer makes OAuth access grant to the Installer App with these scopes:

Access Azure Service Management as organization users (preview)
Read and write to all app catalogs
Read and write directory data
Sign in and read user profile
Read and write all users' full profiles
Read and write directory data
Read and write all applications
Manage apps that this app creates or owns

Installer obtains Access Token 1 with permissions above. *1
Installer creates the App in the customer's tenant. See Create App Request Example
Installer adds a password to the App. See Add Password Request Example
Customer makes a further OAuth access grant to the Installer App with this scope:

Access Azure Service Management as you (preview)

Installer obtains Access Token 2 with permission above.
Customer makes a further OAuth access grant to the Installer App with these Teams scopes:

Read directory data
Maintain access to data you have given it access to
View your email address
Sign in as you

Installer obtains Access Token 3 with permissions above.
Installer prompts the customer to choose the Subscription and create the Resource Group that are required to deploy the Bot.
Installer deploys the Bot in the client's tenant. See Deploy Bot Request Example
Installer generates a zip file that includes the App Manifest and two images. This zip file is required to publish Bot to MS Teams. The contents of the zip file are:

color.png
outline.png
manifest.json

Installer publishes the Bot to the MS Teams app catalog. See Publish Bot In App Catalog Request Example.
Installer installs the Bot in the MS Teams team. See Install Bot In Team Request Example. *2

*1 Installer communicate with MS Graph by Installer App access tokens.
*2 This is where the issue occurs. In most cases, it works and the app indeed added to the team, but in some cases the response for this request is 500 - Failed to execute backend request.
Test environment configuration
portal.azure.com
Added two users USER_1 and USER_2. Both users were assigned the role Global Administrator. Both users use Pay-As-You-Go subscription.
admin.teams.microsoft.com

Teams apps -> Permission policies -> Global (Org-wide default):

Microsoft Apps - Allow all apps
Third-party apps - Allow all apps
Custom apps - Allow all apps

Setup policies -> Global (Org-wide default):

Upload custom apps - ON

The problem
As USER_1 with Global Admin permissions and Pay-As-You-Go subscription I am not able to add custom application (bot) to the Team, in MS Teams UI, owned by me. The Something went wrong modal appears. If we use the Teams web browser client, an HTTP 500 response with the body {errorCode: "AddAppBotToChatRosterFailed"} can be seen in the network monitor.
The app does appear in the Teams app list after the Install Process. But the user who added the application is only able to see it only after re-login. Nevertheless, the application still is not fully added to the team, because the "Add app to team" control remains available (and continue causes a AddAppBotToChatRosterFailed error).
As USER_2, the same initial behavior occurs as with the first user, but after re-login all works ok.
Appendix

Installer App Azure Manifest Example
{
  "id": "c76a5b5b-136d-498b-8b0c-bebe6bcXXXXX",
  "acceptMappedClaims": null,
  "accessTokenAcceptedVersion": 2,
  "addIns": [],
  "allowPublicClient": null,
  "appId": "d159ef8a-4559-4e8f-bfaa-ef68f4fXXXXX",
  "appRoles": [],
  "oauth2AllowUrlPathMatching": false,
  "createdDateTime": "2020-12-28T12:40:18Z",
  "disabledByMicrosoftStatus": null,
  "groupMembershipClaims": null,
  "identifierUris": [],
  "informationalUrls": {
    "termsOfService": null,
    "support": null,
    "privacy": null,
    "marketing": null
  },
  "keyCredentials": [],
  "knownClientApplications": [],
  "logoUrl": null,
  "logoutUrl": null,
  "name": "Installer",
  "oauth2AllowIdTokenImplicitFlow": false,
  "oauth2AllowImplicitFlow": false,
  "oauth2Permissions": [],
  "oauth2RequirePostResponse": false,
  "optionalClaims": null,
  "orgRestrictions": [],
  "parentalControlSettings": {
    "countriesBlockedForMinors": [],
    "legalAgeGroupRule": "Allow"
  },
  "passwordCredentials": [
    {
      "customKeyIdentifier": null,
      "endDate": "2299-12-30T22:00:00Z",
      "keyId": "6fdd26fa-820e-429e-8916-6b993f8XXXXX",
      "startDate": "2020-12-28T15:08:41.968Z",
      "value": null,
      "createdOn": "2020-12-28T15:08:57.2196769Z",
      "hint": "X_S",
      "displayName": "Password uploaded on Mon Dec 28 2020"
    }
  ],
  "preAuthorizedApplications": [],
  "publisherDomain": "TestPublisher.onmicrosoft.com",
  "replyUrlsWithType": [
    {
      "url": "https://sdkapi.staging.api.onereach.ai/http/c1d91ff9-e7bf-464a-90d7-45fb9f2XXXXX/azure/installer",
      "type": "Web"
    },
  ],
  "requiredResourceAccess": [
    {
      "resourceAppId": "797f4846-ba00-4fd7-ba43-dac1f8f63013",
      "resourceAccess": [
        {
          "id": "41094075-9dad-400e-a0bd-54e686782033",
          "type": "Scope"
        }
      ]
    },
    {
      "resourceAppId": "00000003-0000-0000-c000-000000000000",
      "resourceAccess": [
        {
          "id": "1ca167d5-1655-44a1-8adf-1414072e1ef9",
          "type": "Scope"
        },
        {
          "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
          "type": "Scope"
        },
        {
          "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
          "type": "Scope"
        },
        {
          "id": "204e0828-b5ca-4ad8-b9f3-f32a958e7cc4",
          "type": "Scope"
        },
        {
          "id": "19dbc75e-c2e2-444c-a770-ec69d8559fc7",
          "type": "Role"
        },
        {
          "id": "1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9",
          "type": "Role"
        },
        {
          "id": "18a4783c-866b-4cc7-a460-3d5e5662c884",
          "type": "Role"
        }
      ]
    }
  ],
  "samlMetadataUrl": null,
  "signInUrl": null,
  "signInAudience": "AzureADandPersonalMicrosoftAccount",
  "tags": [],
  "tokenEncryptionKeyId": null
}

Create App Request Example
{
  method: 'post',
  url: 'applications',
  headers: {
    authorization: ACCESS_TOKEN_1
  },
  body: {
    displayName: 'App Display Name',
    requiredResourceAccess: [
      {
        resourceAppId: "00000003-0000-0000-c000-000000000000",
        resourceAccess: [
          {
            "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
            "type": "Scope"
          },
          {
            "id": "1ca167d5-1655-44a1-8adf-1414072e1ef9",
            "type": "Scope"
          },
          {
            "id": "c529cfca-c91b-489c-af2b-d92990b66ce6",
            "type": "Role"
          },
          {
            "id": "eb6b3d76-ed75-4be6-ac36-158d04c0a555",
            "type": "Role"
          },
          {
            "id": "a267235f-af13-44dc-8385-c1dc93023186",
            "type": "Role"
          },
          {
            "id": "70dec828-f620-4914-aa83-a29117306807",
            "type": "Role"
          },
          {
            "id": "19dbc75e-c2e2-444c-a770-ec69d8559fc7",
            "type": "Role"
          },
          {
            "id": "62a82d76-70ea-41e2-9197-370581804d09",
            "type": "Role"
          },
          {
            "id": "1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9",
            "type": "Role"
          },
          {
            "id": "7b2449af-6ccd-4f4d-9f78-e550c193f0d1",
            "type": "Role"
          },
          {
            "id": "741f803b-c850-494e-b5df-cde7c675a1ca",
            "type": "Role"
          },
          {
            "id": "294ce7c9-31ba-490a-ad7d-97a7d075e4ed",
            "type": "Role"
          },
          {
            "id": "75359482-378d-4052-8f01-80520e7db3cd",
            "type": "Role"
          },
          {
            "id": "658aa5d8-239f-45c4-aa12-864f4fc7e490",
            "type": "Role"
          }
        ]
      }
    ],
    signInAudience: 'AzureADandPersonalMicrosoftAccount',
    web: {
      implicitGrantSettings: {
        enableIdTokenIssuance: false,
        enableAccessTokenIssuance: true
      },
      redirectUris: [
        "https://em.staging.api.onereach.ai/http/873c0f61-4dfc-4f8a-860e-f574616XXXXX/msteams/oauth"
      ]
    }
  },
  version: 'beta', // MS Graph API version
}

Add Password Request Example
{
  method: 'post',
  url: `applications/${APP_ID}/addPassword`,
  headers: {
    authorization: ACCESS_TOKEN_1
  },
  body: {
    passwordCredential: {
      displayName: 'Generated Secret Password'
    }
  },
  version: 'beta',
}

Deploy Bot Request Example
{
  method: 'put',
  url: `subscriptions/${SUBSCRIPTION_ID}/resourcegroups/${RESOURCE_GROUPE_NAME}/providers/Microsoft.Resources/deployments/${DEPLOYMENT_NAME}?api-version=2020-06-01`,
  headers: {
    authorization: ACCESS_TOKEN_2
  },
  body: {
    properties: {
      mode: 'Incremental',
      template: {
        "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
        "contentVersion": "<IP_ADDRESS>",
        "parameters": {
          "app_id": {
            "defaultValue": APP_ID,
            "type": "String"
          },
          "botService_name": {
            "defaultValue": BOT_NAME,
            "type": "String"
          },
          "botServices_endpoint": {
            "defaultValue": 'https://em.staging.api.onereach.ai/http/c1d91ff9-e7bf-464a-90d7-45fb9f2XXXXX/in/msbot/event/0d1387bf-87c1-4fa9-8aee-d616a0cXXXXX',
            "type": "String"
          }
        },
        "resources": [
          {
            "type": "Microsoft.BotService/botServices",
            "apiVersion": "2018-07-12",
            "name": "[parameters('botService_name')]",
            "location": "global",
            "kind": "bot",
            "properties": {
              "displayName": "[parameters('botService_name')]",
              "iconUrl": "https://docs.botframework.com/static/devportal/client/images/bot-framework-default.png",
              "msaAppId": "[parameters('app_id')]",
              "endpoint": "[parameters('botServices_endpoint')]"
            }
          },
          {
            "type": "Microsoft.BotService/botServices/channels",
            "apiVersion": "2018-07-12",
            "name": "[concat(parameters('botService_name'), '/MsTeamsChannel')]",
            "location": "global",
            "dependsOn": [
              "[resourceId('Microsoft.BotService/botServices', parameters('botService_name'))]"
            ],
            "properties": {
              "properties": {
                "enableCalling": false,
                "isEnabled": true
              },
              "channelName": "MsTeamsChannel"
            }
          }
        ]
      }
    }
  }
}

MS Teams App Manifest Example
{
  "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.5/MicrosoftTeams.schema.json",
  "manifestVersion": "1.5",
  "version": "1.0.0",
  "id": APP_ID,
  "packageName": "com.generated.bot",
  "developer": {
    "name": "onereach",
    "websiteUrl": "https://www.onereach.ai",
    "privacyUrl": "https://www.onereach.ai/privacy",
    "termsOfUseUrl": "https://www.onereach.ai/terms"
  },
  "icons": {
    "color": "color.png",
    "outline": "outline.png"
  },
  "name": {
    "short": APP_NAME,
    "full": ""
  },
  "description": {
    "short": "Generated by OneReach app",
    "full": "This app is generated by OneReach. You can edit manifest.json by your self."
  },
  "accentColor": "#FFFFFF",
  "bots": [
    {
      "botId": APP_ID,
      "scopes": [
        "personal",
        "team",
        "groupchat"
      ],
      "supportsFiles": true,
      "isNotificationOnly": false
    }
  ],
  "permissions": [
    "identity",
    "messageTeamMembers"
  ],
  "validDomains": ["*.onereach.ai"]
}

Publish Bot In App Catalog Request Example
{
  method: 'post',
  url: 'appCatalogs/teamsApps',
  headers: {
    authorization: ACCESS_TOKEN_3,
    'content-type': 'application/zip',
  }
  body: GENERATED_MANIFEST_ZIP_FILE_STREAM,
}

Install Bot In Team Request Example
{
  method: 'post',
  url: `teams/${TEAM_ID}/installedApps`,
  headers: {
    authorization: ACCESS_TOKEN_3,
  }
  body: {
<EMAIL_ADDRESS>`${config.graphApiEndpoint}appCatalogs/teamsApps/${PUBLISHED_APP_ID}`
  },
  version: 'beta'
}

@Jagadeesh-MSFT - could you please look into this issue?

Hi @ja-onereach, Thank you for reaching us, we are working on it, will update you soon.

@Jagadeesh-MSFT Thanks for your follow-up. Apologies if this is being pushy, but I want to reiterate something from the original message:

This is an urgent, blocking problem for us and our customers, so any guidance that could help unblock us immediately would be greatly appreciated. Perhaps there's a hidden means of obtaining a more precise error description, or some reliable workaround steps we could take, or alternative API versions, or other such thing, that we could use while the root of this problem is being addressed. At the moment, some of our customers are entirely unable to create Teams integrations because they can't get past the last installation step and there is no useful indication of what the actual problem is.

As well, I should clarify that we've attempted to automate the app creation and installation process from start to finish, which is what is described in the Detailed issue description section. But we've also tried the process manually, which is where the observations of the "Something went wrong" client error message and browser network responses happened. The problem is the same whether we try adding the app programmatically via the teams/${TEAM_ID}/installedApps endpoint or do it using the manifest.zip file via the web or native clients.
Thanks!

Can we discuss this over call? Could you please write to us at<EMAIL_ADDRESS>

I'd be glad to... I'm free any day after 10am MT if you'd like to pick a
time that's convenient for you.
Thanks!
-jonathan anderson
Jagadeesh-MSFT wrote on 5/18/21 11:39 PM:

Can we discuss this over call? Could you please write to us at
@.*** @.***>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/msteams-docs/issues/3178#issuecomment-843761724,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIFC2AAT3Z4OA64EWNJUMATTONFKBANCNFSM43TL4VKA.

Hi @@.***>, I'm scheduling this call on your's Monday morning 9:00AM MT. I hope it would work for you, otherwise please let me know your available time.
Thanks & Regards,
Jagadeesh Lankireddy

Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meetinghttps://teams.microsoft.com/l/meetup-join/19%3Ameeting_NTgyYmY4N2MtZGE0Zi00NzQ5LThmYzItZjkzNjk3ZjFkMGNi%40thread.v2/0?context={"Tid"%3A"72f988bf-86f1-41af-91ab-2d7cd011db47"%2C"Oid"%3A"7aed6015-3632-44dd-8559-84e649bc5b6b"}
Or call in (audio only)
+91 22 6219 2547,,,,222654849#tel:+912262192547,,,,222654849#   India, Mumbai
0008000402025,,,,222654849#tel:0008000402025,,,,222654849#   India (Toll-free)
Phone Conference ID: 222 654 849#
Find a local numberhttps://dialin.teams.microsoft.com/576c8211-dbe8-4a9a-8707-1b52ccc23231?id=222654849 | Reset PINhttps://mysettings.lync.com/pstnconferencing
Learn Morehttps://aka.ms/JoinTeamsMeeting | Meeting @.***&messageId=0&language=en-US>

From: Jonathan Anderson<EMAIL_ADDRESS>Sent: 20 May 2021 00:39
To: MicrosoftDocs/msteams-docs<EMAIL_ADDRESS>Jagadeesh-MSFT<EMAIL_ADDRESS>Microsoft Teams Dev Community Response<EMAIL_ADDRESS>Subject: [EXTERNAL] Re: [MicrosoftDocs/msteams-docs] Custom app installation fails with "Something went wrong" (AddAppBotToChatRosterFailed) error (#3178)
I'd be glad to... I'm free any day after 10am MT if you'd like to pick a time that's convenient for you.
Thanks!
-jonathan anderson
Jagadeesh-MSFT wrote on 5/18/21 11:39 PM:
Can we discuss this over call? Could you please write to us at<EMAIL_ADDRESS>

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fmsteams-docs%2Fissues%2F3178%23issuecomment-843761724&data=04|01|v-jaglan%40microsoft.com|3c55f8693ed747187a1408d91af987a2|72f988bf86f141af91ab2d7cd011db47|1|0|637570482211613786|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|0&sdata=8GZshKbosLtOsfVcwfNZZgaBCMcJP6e0MFizBmP9%2Fsk%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIFC2AAT3Z4OA64EWNJUMATTONFKBANCNFSM43TL4VKA&data=04|01|v-jaglan%40microsoft.com|3c55f8693ed747187a1408d91af987a2|72f988bf86f141af91ab2d7cd011db47|1|0|637570482211623780|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|0&sdata=wrwEOAY9fshJHbNl0oQLs%2FvjN1qNBnemKwd50z%2FWQQA%3D&reserved=0.

I also had this same issue when I tried to install a custom app in MSFT teams. In my case, I was able to fix it by adding the MSFT teams channel in Azure portal under the bot service channels section.

I have a similar issue, in my case I can register the bot without problems when my AAD registered app has "accessTokenAcceptedVersion": null but after i change it to  "accessTokenAcceptedVersion": 2 it starts to throw this "AddAppBotToChatRosterFailed" exception when I'm uploading the MS Teams manifest.
Maybe it's because the null/1 version uses different format of the audience claim than the 2 version? 1/null sets my audience claim as api://<APP_DOMAIN>/<AAD_APP_ID>, but the 2 version sets it as just the <AAD_AAP_ID>.
That's what I think, but I'll be debugging it further in the upcoming weeks, it would be really nice to be able to use the 2 version.

Thanks to @santhoshkr047 and @marcinburak for adding their observations here. The variety of potential causes of the same error underscores what I think is the real, critical issue here: this single error message encompasses too many possible actual underlying causes such that people have to guess their way to a solution instead of being pointed directly to it by the error message. Instead of seeing AddAppBotToChatRosterFailed or just "Something went wrong," if we saw errors like "Could not add app bot to chat roster because Teams is not enabled in Bot Channels Registration" or "...this Teams user is not permitted to install 3rd-party apps" or "...because the provided access token version is prohibited for the 'POST appCatalogs/teamsApps' method", people would be able to dig themselves out of their own holes. The problem probably isn't that there's a bug in sideloading apps, it's that the success of that action is subject to too many obscure variables in the compound intersection of Graph API methods, Azure resources, Azure security settings, AAD permissions, Teams security settings, and Teams user permissions.

In case it helps anyone else, here are the instructions we've been giving our customers that run into this:
The problem is most likely related to what Microsoft describe as “side-loading” apps, which seems to mean uploading the manifest instead of getting it from a marketplace, and the security and permissions settings that bear on that activity. Please go to https://admin.teams.microsoft.com and check the following sections:

Teams apps > Permission policies : Is there a policy that allows 3rd-party and custom apps to be installed by the installing user?
Teams apps > Setup policies : Is uploading of custom apps allowed?
Teams apps > Manage apps : Can you find an installation of the app in this list? If you click the Org-wide app settings do they indicate that users are allowed to install 3rd-party apps and interact with custom apps?

If you're unable to see or access any of those sections in the Teams admin center, you need to get the help of your Teams admin or get your Teams admin to elevate your privileges. With luck, this is all just some obscure issue related to permissions and security settings that were overlooked previously. Otherwise you need to undertake a process to isolate and confirm the issue while generating the data we need to send to Microsoft to get their help finding a solution.
At every juncture where an error occurs or something seems to fail, please note the specific activity and the precise date, time, and timezone when it occurred. Then sign out of Teams, quit the application, then open it again and sign in again before proceeding to the next step. Apparently there are known issues with caching so it's necessary to try to exclude that as a variable.

Confirm that all of the settings above are correct and you’re signed in as a user who has permission to upload/install 3rd-party and custom apps.
Check to see whether the app already appears in the Manage apps section or the “Built for your org” list in the Apps area of the Teams client.
If it does, try again to add that app to a channel. Note I’m saying add it to a channel instead of a team. Click the little caret next to the “Add” button and choose “Add to a chat”, then choose some existing channel in a team.
Even if that seems to fail, try @ mentioning the bot in that channel anyway. If you’re able to do that, check the logs in your account in our system to see if the event was received. If it was, then the installation only appeared to have failed but didn’t. If it’s possible to @ mention the bot but the activity isn’t hitting our system, stop there and let us know because that’s a completely different category of problem.
If it’s not possible to @ mention the bot, try adding it to the team instead of to a channel. Click the little caret next to the “Add” button and choose “Add to a team”.
Even if that seems to fail, try starting a DM chat with the bot and send it a message. If you’re able to do that, check the logs in your account in our system to see if the event was received. If it was, then the installation only appeared to have failed but didn’t. If it’s possible to send a DM chat message to the bot but the activity isn’t hitting our system, stop there and let us know because that’s a completely different category of problem.
Try deleting the app from the team, as well as any other apps that might have been created through previous attempts. Log out of Teams, quit the application, then open it and log back in again.
Try uploading the app manifest from Teams admin center (https://admin.teams.microsoft.com/policies/manage-apps) instead of the Teams client. Repeat steps 2-6.

One of our customers that's been having this problem reported that the cause turned out to be the Azure subscription they were trying to use had been disabled or deactivated somehow. They fixed that and were able to proceed.
We had previously received guidance from Microsoft that we should try installing a custom app via the Teams admin center rather than the Teams client. In my experience, that causes the "Something went wrong" error 100% of the time, so I recommend only installing it from the Teams client.

@Jagadeesh-MSFT I have a similar issue, always getting  "Something went wrong" (AddAppBotToChatRosterFailed) error when trying to add the custom bot. Have any news about this problem??

@ja-onereach - Could you please confirm if your issue has resolved or still looking for any help?

@v-chetsh I can't say it's really been resolved, we're just learning to work around it. The fundamental problem here is that many possible configuration issues can result in the same, unspecific error message so it's exceedingly hard to identify the specific problem(s) in the specific tenant at hand.

Maybe not totally related, but I get the same error once I add a bot to my 'manifest.json'-file. If I leave the bot property empty, it installs just fine. This just happened during the 'Develop apps for Microsoft Teams – Associate' MS Learn course at 'Exercise - Using task modules with bots'.
{   "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.11/MicrosoftTeams.schema.json",   "manifestVersion": "1.11",   "id": "{{APPLICATION_ID}}",   "version": "{{VERSION}}",   "packageName": "{{PACKAGE_NAME}}",   "developer": {     "name": "Contoso",     "websiteUrl": "https://{{PUBLIC_HOSTNAME}}",     "privacyUrl": "https://{{PUBLIC_HOSTNAME}}/privacy.html",     "termsOfUseUrl": "https://{{PUBLIC_HOSTNAME}}/tou.html"   },   "name": {     "short": "YouTube Player",     "full": "YouTube Player"   },   "description": {     "short": "TODO: add short description here",     "full": "TODO: add full description here"   },   "icons": {     "outline": "icon-outline.png",     "color": "icon-color.png"   },   "accentColor": "#D85028",   "configurableTabs": [],   "staticTabs": [     {       "entityId": "221e7a8b-aa32-4feb-8a10-75595a75aa12",       "name": "YouTube Player 1",       "contentUrl": "https://{{PUBLIC_HOSTNAME}}/youTubePlayer1Tab/?name={loginHint}&tenant={tid}&theme={theme}",       "scopes": [         "personal"       ]     }   ],   "bots": [     {       "botId": "{{MICROSOFT_APP_ID}}",       "scopes": [         "personal"       ],       "commandLists": [         {           "scopes": [             "personal"           ],           "commands": [             {               "title": "MentionMe",               "description": "Sends message with @mention of the sender"             }           ]         }       ]     }   ],   "connectors": [],   "composeExtensions": [],   "permissions": [     "identity",     "messageTeamMembers"   ],   "validDomains": [     "{{PUBLIC_HOSTNAME}}"   ],   "showLoadingIndicator": false }

@dmitriyvde - Could you check if you have added MS Teams in the channels part of bot channel registration.
@ja-onereach - Could you please let us know what is the current issue you are facing? Also please share the repro steps.

@Meghana-MSFT Our problem is a little bit complicated, a little bit meta. Our product is a platform that people use to create automation, chatbot, integration, and other such systems, and we offer a collection of tools for working with Teams bots. Very often when one of our customers tries to create a bot app for Teams, they get completely stuck because the app installation fails with this vague "Something went wrong" error. The actual, underlying reason for the error is seemingly different for every customer based on the idiosyncrasies of their Azure and O365 tenant configurations and random errors they might have made. I've listed some of the different reasons we've seen before in my previous messages here.
If you consider how many different possible configuration issues, security or access limitations, and errors (or multiple, cooccurring instances of any of those) can lead to "Something went wrong" it makes it extremely hard to figure out how to fix the problem. Every one of our customer's Azure/O365 tenants is a vast sea of complexity and idiosyncrasy and subject to different access restrictions, so every occurrence of this error requires a complicated investigation. So when I said "we're just learning to work around it," I meant that every time we encounter this we add another item to the list of things to check next time it happens. This has taken the troubleshooting process down from 2-3 weeks to a few days, but if the error message could report specifically what failed people would be able to get past this immediately and without an onerous process of investigating Azure/O365 resources and settings.

@Meghana-MSFT Yes, I have done everything as describe here in the MS learn module.
A bit off topic:
I might also want to add that I have reported quite a lot of feedback on these pages in terms of 'Learning content quality' since a lot of the subject matter on teams is simply outdated and a pretty much nothing in the whole MS Learn path for Teams works with de described screenshots/code snippets. As a newcomer and someone that is soon going to attempt the MS-600 exam I am really doubting this part of the exam. Are the questions even going to be relevant by the time I attempt the exam or will they be about outdated/non-working ways of working with Teams apps? Sure I could go to other places to learn these things, but then what's the point of having a learn path on this subject matter in the first place? I understand that Teams is a rapidly evolving platform and things get added pretty much all the time, but then just add a disclaimer at the top or something that the content probably doesn't apply anymore.

@ja-onereach - Thanks for providing the inputs, We are checking this internally. We will get back to you.

@ja-onereach -

Could you please share the request and response ids of any recent failure you have observed. We will investigate it internally. Please make sure you have removed any PII.
We will forward this feedback to the concerned team to include details related to the failure.

@DmitriyVdE - We will try to repro the issue by following the above mentioned MS learn module. and get back to you.

@ja-onereach - Could you please share the above requested details?

@Meghana-MSFT @Jagadeesh-MSFT  I am following MS learn module for building bot for teams and facing different issues since then:

When we generated the bot project with yo teams, why do we still need to use app studio and perform the same steps twice?
I created bot with 'single tenant' bot type and on testing, it throws error in my terminal 'error: get token request returned http error: 400 and server response: {"error":"unauthorized_client","error_description":"aadsts700016: application with identifier XXXX'
Then I created a fresh bot with Multi tenant and update my env variables but now when I try to upload my app, it gives the error 'Something went wrong' with status 400 and code as "AddAppBotToChatRosterFailed".

This is frustrating as I am struggling even in following the tutorial for 2 days.  Here is the manifest in zip file.
{   "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.9/MicrosoftTeams.schema.json",   "manifestVersion": "1.9",   "id": "15327820-7ecc-11ec-ad8f-c540a8a3dbdb",   "version": "0.0.2",   "packageName": "conversationalbot",   "developer": {     "name": "Codeterian",     "websiteUrl": "https://ed40-88-192-41-19.ngrok.io",     "privacyUrl": "https://ed40-88-192-41-19.ngrok.io/privacy.html",     "termsOfUseUrl": "https://ed40-88-192-41-19.ngrok.io/tou.html"   },   "name": {     "short": "Conversational Bot",     "full": "Conversational Bot"   },   "description": {     "short": "TODO: add short description here",     "full": "TODO: add full description here"   },   "icons": {     "outline": "icon-outline.png",     "color": "icon-color.png"   },   "accentColor": "#D85028",   "configurableTabs": [],   "staticTabs": [],   "bots": [     {       "botId": "49d81788-1845-4cae-9cdf-562679c84e1d",       "needsChannelSelector": true,       "isNotificationOnly": false,       "scopes": ["team", "personal"],       "commandLists": [         {           "scopes": ["team", "personal"],           "commands": [             {               "title": "Help",               "description": "Shows help information"             },             {               "title": "Who am I?",               "description": "Shows information about your Teams user"             },             {               "title": "Mention me",               "description": "Let the bot @mention you"             }           ]         }       ]     }   ],   "connectors": [],   "composeExtensions": [],   "permissions": ["identity", "messageTeamMembers"],   "validDomains": ["ed40-88-192-41-19.ngrok.io"],   "showLoadingIndicator": false }

Hi @Nikitha-MSFT @Wajeed-msft,
Can you please help on this issue?

@ekansh005 - We are checking it. We will update you soon.

@ekansh005 -

I skipped the app studio and was still able to run the bot.
I tested with multitenant bot and it is working fine at our end.
I have tried with the manifest you shared, I was able to upload it successfully. Could you confirm if you are still facing the issue?

Hi,
I would check this in a couple of days.

Hi @Meghana-MSFT ,
I am still facing the same issue. PFA the screen recording and the package where I replicate the issue.
https://1drv.ms/u/s!AmbUIBxAPz3VbqPucbyjrtoDvWA?e=M2utFt

Sorry for the slow reply, I responded to the equivalent question in a support email thread and thought that was enough. I don't have any ongoing unresolved instances of this problem so unfortunately I can't share the requested details right now. The next time I hear from a customer encountering this problem I'll share whatever details I can. Let me copy what I said in the email thread here,:

Please consider what I've already said a few times on that thread: this isn't just one incidence of this problem in one tenant that we need help troubleshooting, it's a recurring incident across many tenants under variable circumstances. I can't give you specific steps to reproduce it right now because we've resolved the cases we were facing before, and anyway those are not occurring in our tenants, they're happening in our customers'. Honestly the way to reproduce this problem for yourselves is to ask people who are not experts in Azure and who don't have god-level permissions in their tenants to try to get started using a Teams bot app in a variety of real-world, complicated Azure and O365 instances, and just watch what they have to go through. As noted in the thread, sometimes it's a subscription issue, sometimes a problem with the bot channels registration, sometimes some sort of permissions issue or a restriction on side-loading apps, sometimes an issue with a schema or API version being used, sometimes it's because you tried installing it from the Teams admin area instead of the client, sometimes it's the inverse. Seemingly dozens of different little problems result in the same error message, making this a nightmare to troubleshoot each time.

At this moment, our request is less of a support ticket and more of a plea—speaking as someone who is frequently trying to help Azure and O365 customers on their journey to using Teams bot apps—to make it easier to get started, or make it less susceptible to this error that halts all progress, or at least make the error message actually informative. It takes about 10 minutes to set up a bot integration with Slack, Zoom, and Webex Teams, and troubleshooting problems takes maybe a half an hour; getting started with Microsoft Teams bots usually takes hours under good conditions and days or weeks under others. Even if you manage to get something installed, with Teams instead of just learning one API or SDK you have a vast range of complicated new things to learn... but I suppose that's off-topic for this specific issue.

When this issue comes up again I'll ask the affected customer to send me as much detail as they can and also make their own support request to Microsoft, but if we keep viewing this as a single incident needing troubleshooting we'll be missing the real problem. We've done a ton of work to create tools that make it easy for people to build conversational and other automation behaviors in teams, but none of that is worth anything until customers can get their app installed.


toCapitalCase is not showing special character

string like
'house # 1234'.toCapitalCase() // House 1234
any solution

@iamaz007 presumably the way to handle this would be to use the ChangeCaseConfig.setUp method, but there is a bug with doing that. I created #6 to address this.


Lithium plating

Description
-A thermal prefactor has been added to the reversible and irreversible plating submodels, allowing them to be used for models where the temperature varies
-These models now use delta_phi as an input instead of phi_s and phi_e, which should lead to minor performance improvements
-The "Lithium plating kinetic rate constant [m.s-1]" parameter has been restored and integrated into the new framework, so people who aren't plating experts can adjust it.
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.

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

Key checklist:

[x] No style issues: $ flake8
[x] All tests pass: $ python run-tests.py --unit
[x] The documentation builds: $ cd docs and then $ make clean; make html

You can run all three at once, using $ python run-tests.py --quick.
Further checks:

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

Can you merge develop? It should get rid of all the lines in the unit test so we can see what's going on


Crash with Ceramics

i am aware of crash when ceramics is not loaded.

This also concerns Pyrotech. 😉

i am also aware of that one(i just didn't mention it). it's fixed already anyways


Set up GitHub actions for testing dbt-helper.

I have a slight preference for github actions over circle CI, but also circle CI seems to be working just fine so not sure if it's worth the extra lift. It'd be nice to at least add the automatic running of black against pull requests.


Bug: invalid description for the validation message in 'spo file checkout'

In spo file checkout we show an invalid validation message here:
https://github.com/pnp/cli-microsoft365/blob/119724d0ee251808a51477b6bbf4a0a9f89136ed/src/m365/spo/commands/file/file-checkout.ts#L91
and here:
https://github.com/pnp/cli-microsoft365/blob/119724d0ee251808a51477b6bbf4a0a9f89136ed/src/m365/spo/commands/file/file-checkout.ts#L95
In both cases we refer to the UniqueId property instead of fileUrl

If I'm not mistaken, the validation message should be 'Specify either id or fileUrl but not both' right?
I can correct this if you like.

Correct. Please do @milanholemans! We appreciate your help 👏


Use ES6 module import syntax instead of the require syntax

I was trying to use the library in a new project which leverages the new modules tag: https://caniuse.com/#feat=es6-module (in combination with webcomponents). Wanted to build some project with this library, but it seems this project is using the old require() syntax.

@ai Any thoughts?

Sounds to me like he's not using webpack.

You can use require() in any Node.js module, so having ES modules will give only a more cute syntax, but not a real use case.
In webpack ES modules will be able to use tree-shaking, but I am not sure, that it will give any benefits for caniuse-lite API.
So, since we are talking only about syntax sugar, if we have a way to provide both CommonJS and ES Modules syntax without any extra problems, so why not? Unfortunately, I am not sure how to provide both syntaxes without having 2 copies of every data file, which will bloat package size.
This is my raw thoughts :D. @paales do you have a plan of adding ES modules syntax support here?

Never responded to this ticket...  sorry! @andyjansson was right, wasn't using webpack, was using a very minimal build system which had an almost empty build step (only path resolution), which caused this to not work.
 :)

I think it is trends driven development, which is not so good.
We always should change technologies only because they are giving benefits, not because it is a trend now.


Remove http2 in KONG_ADMIN_LISTEN env in all in one manifests if Kong version < 3.0.0

Is there an existing issue for this?

[X] I have searched the existing issues

Problem Statement
Part of #5211. Kong 2.8.x does not support HTTP/2 on admin APIs, so we need to remove the http2 in KONG_ADMIN_LISTEN env if kong version is below 3.0.0.
Proposed Solution
Since it is not easy to write a kustomize patch to modify the environment variable in manifests, we may update it after deployment  created like exposeAdminAPI.
Additional information
No response
Acceptance Criteria
No response

I want to implement a kustomize patch to implement it, because the current implementation by modifying the deployment after creating it may bring a problem:
KIC detected the initial Kong gateway pod as the initialKongClients and use them to initialize the Admin API clients manager. Then, the Kong gateway deployment is updated and the old pod is deleted before KIC calling ValidateRoots, then KIC will stickon retrying to get the initial configuration from the gone pod. The request timeouts after 5~10 seconds, then KIC could not start in the waiting time (~3m).


As a disorganised coach, I want to view each task by name or role so that I can get a better view of my schedule

PR related to #73
Implementation is the same as FindCommand class

Codecov Report

Merging #79 (c763d65) into master (3859d78) will increase coverage by 0.25%.
The diff coverage is 87.80%.

@@             Coverage Diff              @@
##             master      #79      +/-   ##
============================================
+ Coverage     73.80%   74.06%   +0.25%
- Complexity      605      626      +21
============================================
  Files           101      105       +4
  Lines          1890     1928      +38
  Branches        205      210       +5
============================================
+ Hits           1395     1428      +33
- Misses          434      436       +2
- Partials         61       64       +3

Impacted Files
Coverage Δ

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
68.00% <0.00%> (-5.92%)
:arrow_down:

.../seedu/address/logic/parser/FindCommandParser.java
83.33% <ø> (ø)

...du/address/logic/parser/FindTaskCommandParser.java
83.33% <83.33%> (ø)

.../seedu/address/logic/commands/FindTaskCommand.java
91.66% <91.66%> (ø)

...java/seedu/address/logic/commands/FindCommand.java
91.66% <100.00%> (ø)

.../seedu/address/logic/commands/ListTaskCommand.java
100.00% <100.00%> (ø)

.../model/tag/PersonTagContainsKeywordsPredicate.java
100.00% <100.00%> (ø)

...ss/model/tag/TaskTagContainsKeywordsPredicate.java
100.00% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Amazon clone added

🛠 Fixes Issue
Closes #234

👨💻 Changes proposed
Amazon Clone added & not deployed yet

✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots / Videos

https://user-images.githubusercontent.com/73753957/161426700-b670c0fa-faa0-48c3-8e9b-8c7a1f407a32.mp4

@Rayman-Sodhi the last merge has some issues so both PR connected each other and if I merge first PR second one automatically merged, so please review this and add a label


Could you release small/tiny/nano version of detector and descriptor?

Hello, thank you for your amazing job!
I'm really interesting of your job and want to deploy DeDoDe on mobile devices(laptop, even CPU) for some self-driving works.
But I find it is too heavy for mobile device to run DeDoDeDescriptorB, DeDoDeDetectorL.
In my computer(RTX4060 mobile 8G), only 5.4 fps when inputs with 640*320 (tensorrt_fp16)
Could you release small/tiny/nano version of detector and descriptor?
Thank you in advance!

Sure, the easiest I guess would be using vgg11 and reducing layers further. Should be doable. Not sure how much performance will degrade.

about 30fps in RTX4060 mobile 8G.

@zhongqiu1245 could you try out the small detector in the branch that references this issue?
Weights can be found here: https://github.com/Parskatt/DeDoDe/releases/tag/v2

Depending on your application it might also be possible to increase the framerate by batching, is this an option for you?

@Parskatt
Sorry for reply so late.
I will verify this.
Thank you!

@Parskatt
Thank you for your DetectorS!
The fps increases rapidly, but still lower than 30fps (only 16fps, DetectorS + DescriptorB, 640480, tensorrt fp16).
So I reduce the shape of img to 320240, then fps=25, almost there.
Could you release a small version of Descriptor? Like DescriptorS?
Maybe this can help DoDeDo breaks up the limitation of 30fps.
Thank you!

Sure, then I think we can also reduce descriptor size. Does 128 sound better? Is descriptor dimensinality a concern?

Thank you for your reply !
128 sounds better.
Yes, dim is an important factor which can speed up/slow down the inference time of net.The dim is smaller, the speed is faster. However, if dim is too small, it will cause bad performance. I thought dim=64 before but I thought it maybe too small. 128 maybe better :)
Thank you for your generous!

Okay, so seems like around 20fps is at least possible with current sizes.
Are you able to extract the times for the encoder/decoder parts of the network? Depending on what is taking most time might need to change enc architecture.
The final thing I guess would be to distill both networks into a single network.

ok, I will try later.


[1.12.0-rc2] Joining a remote node without --manager doesn't require acceptance

Output of docker version:
Client (laptop, OSX)
$> docker version
Client:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd
 Built:        Fri Jun 17 20:35:33 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   a7119de
 Built:        Fri Jun 17 22:09:20 2016
 OS/Arch:      linux/amd64
 Experimental: true

Server:
Client:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd-unsupported
 Built:        Fri Jun 17 21:21:56 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd-unsupported
 Built:        Fri Jun 17 21:21:56 2016
 OS/Arch:      linux/amd64

Output of docker info:
Client:
Containers: 78
 Running: 0
 Paused: 0
 Stopped: 78
Images: 51
Server Version: 1.12.0-rc2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 344
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge null host
Swarm: inactive
Runtimes: default
Default Runtime: default
Security Options: seccomp
Kernel Version: 4.4.13-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.954 GiB
Name: moby
ID: AX3N:B5KC:6TY6:V5UW:5MAH:JSD3:PXBN:HC3H:GF3L:GC7L:Z35R:KAIW
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 33
 Goroutines: 95
 System Time: 2016-06-20T22:09:37.819574454Z
 EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 <IP_ADDRESS>/8

Server (swarm cluster):
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.0-rc2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay host null bridge
Swarm: inactive
Runtimes: default
Default Runtime: default
Security Options: apparmor seccomp
Kernel Version: 4.4.0-24-generic
Operating System: Ubuntu 16.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 991.1 MiB
Name: docker1
ID: LOR7:TUJW:PXCF:SGKX:L5LU:GQCT:UTRN:G72M:JU32:I24J:JN3R:BN34
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Steps to reproduce the issue:

Set up a remote swarm cluster - mine is 4 remote nodes, 2 leaders
On your laptop, run:

$> docker swarm join swarmIP:2377
This node joined a Swarm as a worker.

On the leader:

docker node ls
ID                         NAME     MEMBERSHIP  STATUS  AVAILABILITY  MANAGER STATUS
09y7cdu03xmuwhta0ykvd72gb  docker4  Accepted    Ready   Active        Reachable
1jkzrkblwbdig3l5u29997n00  docker1  Accepted    Ready   Active        Leader
41znz1ntskwvvvea8up52wu0m  docker2  Accepted    Ready   Active
5bt1bcak4tuzm9a39a7ou9upz  docker3  Accepted    Ready   Active
7ljlfo1zqcid0mc8cmir64i6g  moby     Accepted    Ready   Active

Describe the results you received:
My 'rogue' laptop was able to join the swarm cluster as a worker and shows up in the manager list as ready and active.
Describe the results you expected:
I expected the join command to require approval from a manager node as it does in manager mode
Additional information you deem important (e.g. issue happens only occasionally):

/cc @vieux ptal

Our current default automatic acceptance policy is to allow workers and deny managers. This can be configured in docker swarm init/update by setting --auto-accept=none to turn this feature off or --auto-accept=worker --auto-accept=manager to allow everything. Another good way to configure this is to set a --secret that needs to be provided on join in addition to the policy rules.
I agree that we should communicate more clearly what implications the default policy has, when you would want to use it and when you definitely want to use some extra options.
@diogomonica @aaronlehmann

Correct, this works as intended. The default policy has managers on manual-approval, and workers on auto-approval. This can be changed by passing parameters to docker swarm init that change that behavior, or using update after the fact.

Correct, this works as intended. The default policy has managers on manual-approval, and workers on auto-approval. This can be changed by passing parameters to docker swarm init that change that behavior, or using update after the fact.

This seems like bad behavior by default (even if intended). Unless you know what you're doing and using a private / encrypted network for your entire swarm, I could just join as a worker and be assigned work/containers/etc.
It would be fairly trivial to port scan a block for the open swarm/manager ports and join up. IMO the default should be to always manual approve unless the manager/init is set to 'auto approve workers'

While I know you're balancing security with ease of bootstrapping, if a rogue worker joins without approval it's automatically trusted. It gets the pem files / certs from the rest of the swarm which means if you did identify a rogue worker you'd have to revoke/roll the entire clusters certs.

@jnoller that is not true: you would only have to remove the node from the cluster, and it would lose immediate access to the swarm. No further revocation/rotation would be necessary.
We believe that this currently provides the best balance between security and usability, and the fact that:

Swarm mode doesn't come turned on by default, it requires an explicit init
The fact that it is absolutely trivial to both setup further barriers to entry of worker nodes (either auto-accept or secret will work) on swarm mode initialization, or by using update at a later time.
The fact that to remove illegitimate nodes you simply need to run a docker node rm

make this an acceptable default for swarm mode.
This said, we're obviously always looking for more data-points and community feedback, and if auto-accepting worker nodes become an issue, we will change the default.

@diogomonica Sure, it is just a node rm - but first you have to know there is a rogue worker - take the on-stage example of spinning up 100 ec2 instances with $N managers. The operator would have to have scripting to identify any worker that came online as 'not what I wanted, who is this chap?' and then rm that node.
Reason I brought this up is that I think we all learned a bit from the redis stuff (http://antirez.com/news/96) balancing security vs. usability, the defaults allow me to join any swarm, get containers / volumes / services assigned to me and so on.
I know swarm mode isn't on by default - with 1.12 though you've changed some fundamental aspects (for the better) but implicit opt-in for workers seems like a bad idea.

@jnoller In a setup like that you would be deploying all of your managers and workers inside of a VPC, and the ELBs would expose the ports that should actually be accessible from the outside. This means that no one from the outside would be ever be able to propose itself as a member of the swarm.
Even though I understand your basic point with the redis example: we would rather not have open-membership for anything, I think the major issue with redis was that for the longest time there was no way to secure redis, and when it came, it took significant extra effort to configure. I think you'll agree, using --secret on the init for a production swarm is absolutely trivial (or even using update after the fact).
As of right now, given the following assumptions:

auto-accept, for worker nodes only, significantly improves the developer/ops experience of setting up a new swarm.
Worker nodes only listen for tasks, and don't have any ability to control/affect the swarm other than running tasks that were scheduled on them.
It is easy to reconcile the number of nodes you are supposed to have in the system, and the number of nodes you actually have (docker node ls | wc -l).
It is absolutely trivial to change it/add more barriers to entry (via --secret or --auto-accept none).
We can never chose to go to auto-accept if at a later time we later decide that it would be a good usability trade-off.
Good documentation around ensuring that either auto-accept is turned off or secret is turned on is enough to incentivize people to do the right thing (given that it is trivial to do the right thing).

then I believe we should keep the current defaults.
Additionally, the direction that the swarm functionality (and swarmkit) are going in, is to provide the ability for administrators to configure secure labels on hosts, to allow certain containers from only being deployed on hosts with certain tags. This will further reduce the impact a malicious worker node would have in the system, since it wouldn't be able of receiving any task that leaks anything sensitive.
Finally, let me just say that this is simply my opinion. Even though I work for Docker, it is always up to the community to decide the path that the project should take. If other people share the same view as you, that this ultimately will be prejudicial for the security of Docker users in a way that trumps the benefits of having it open by default, I will open the PR to change it myself :)
Thanks for caring about the security of Docker!

@diogomonica From an ease of use standpoint I agree with you. This totally makes things easy to use. I remember having this same debate at Puppet Labs back in the day. Puppet uses a similar method to handle membership and the decision was made to be secure by default and make auto-accept opt-in.
What Puppet Labs found back then is that some users were unaware of the dangers behind auto-accept until it was too late. Given how well the UX is around the initial setup I think requiring a single flag to opt-in to auto-accept only slightly diminishes the user experience and helps people do the right thing out of the box.
If it's determined that auto-accept should be on by default, then I would like to suggest that a warning be printed that you are running in auto-accept mode for worker nodes, and also print the commands and/or link to documentation that people can use to lock things down and disable auto-accept

I'm leaning towards having it disabled by default; adding an --auto-accept flag or adding it to the daemon.json configuration file sounds like an easy task

We can never chose to go to auto-accept if at a later time we later decide that it would be a good usability trade-off.

Sorry, I didn't really understand this one; could you explain?

I like the warning upon swarm init cc @sfsmithcha

cc @diogomonica

I would really like to avoid warnings. They are essentially shifting the blame to the user by allowing us to claim that "they should have read it". Either it is ok that workers are accepted by default in practice (which I still believe it might be), or it is not. If it is ok, we ship with no warnings, and if it is not, we change the default.
I'll take all the feedback and meet with the security team at docker to reconsider. Thanks everyone for jumping in.

I'd rather change the default, but if we don't then at least a warning with link to docs about securing the swarm. The current situation is worse than any of those 2 IMHO.

Related: #24140.
After reading the discussion here I switched my opinion to favour disabling all auto-accept by default. There is a related issue though where docker swarm update --auto-accept does not allow you to have a scenario where both are auto-accepted (#24140) .

FWIW, I vote for secure default in swarm --auto-accept=none. In the docs we can set auto-accept for workers in the tutorial (where users don't want to deal with acceptance) with a warning there, which is better than an in-product warning.

:heart: for --auto-accept=none as default.
imagine I'm at a conference and follow the tutorial on my linux (naively setup) notebook, after hearing how Docker is secure by default...

FWIW from the perspective of a security person, I'd argue for --auto-accept=none as the default (as has been said it's fairly easy to change), following the principle of least privilege and "secure by default".
My reasoning for this is that when a swarm is initialized the engine starts listening on network ports which are accessible to anyone who can route traffic to that system,  and the managers doesn't get any notification of new workers joining from what I've seen, so a rogue worker may not be easily detected before a workload is sent to them.
I can tell you from my experience that a lot/most people will leave things in their default configuration, so if the default is auto-accept and no value for secret, that's what a lot of people will leave in place.
Then all the pen.testers/researchers will start scanning for 2377/TCP and connecting to any swarms that can be located....

Totally agree. Else, we add a check in CIS benchmark to make it none.

Also, not sure if you looked at it. Current documentation says that,
"By default, both worker and manager nodes are auto accepted by the cluster."

Thanks for pointing this out @praving5. I opened #24248 to correct the documentation to match present reality.


Export ex data to JSON

https://github.com/blueskythlikesclouds/MikuMikuLibrary/blob/f0e5ebc72358bd3d18ad26993eade5b2888ed7d8/MikuMikuModel/Nodes/Objects/SkinNode.cs#L463
Is it unfinished?

Uh, I don't remember.
Anything wrong with it?

Oh, I'm not the person who coded that, seems it works a bit backwards. It asks you to select .farc/_obj.bin files, then it exports the ex data from the files you selected to .json. Normally, it should export the ex data of the skin node you currently have selected in the UI.
The import JSON code should be functional.

Oh, oh...
Thanks for your explanation. I know how to work around now.

I'll work on fixing this weird UX behavior when I have the chance. Thanks for pointing it out!


chore(deps): bump kataras/iris to 12.2.0-beta7 to resolve vulns

Bumps github.com/kataras/iris from v12.2.0-beta5 to v12.2.0-beta7 to resolve some transitive vulnerabilities.
Resolves:

GO-2022-1144 / CVE-2022-41717
GO-2023-1495 / CVE-2022-41721
GO-2022-1059 / CVE-2022-32149

The CHANGELOG for v12.2.0-beta7 can be found here.

Hey @mdtro , for additional context, could you link to the changelog, and/or vulnerability report please?

Hey @mdtro , for additional context, could you link to the changelog, and/or vulnerability report please?

Done! Apologies for not including it to begin with. 🙂

Please keep in mind that we're forcing Sentry users to upgrade iris by merging this. This is kinda against our philosophy, but we got a lot of complaints about the Go SDK triggering some false positives in weird security scanners.

@cleptric I understand the concern. We are moving from beta5 to beta7, but that definitely moves a lot of the indirect dependencies forward quite a few versions.
I second the SDKs generating false positives in the various security scanners. I used three different ones and ended up with three different answers. 🙃
v12.2.0-beta7 was released just over 30 days ago, so we want to wait a bit longer for any bugs -- I think that's reasonable.

Let's bite the bullet 😄

Ooph, the checks aren't happy. I'll add this to my list to dig in on early next week.

Part of https://github.com/getsentry/sentry-go/pull/595


Potential tokenizer ordering issue

I think the tokenizers do not explicitly provide tokens sorted by frequency when we call get_vocab()
https://github.com/MinishLab/model2vec/blob/b4927e17494bd03e14ff51c1fa2aca059680df2d/model2vec/model.py#L45
In general the assigned IDs are not guaranteed to be sorted by frequency (though for some tokenizers the ID values may generally align with the frequency)
IMO this may influence the zipf re-weighting step right?

Hey @zechengz,
Thanks for the issue. This is true, but it does seem to help performance in most cases. I also think the vocabularies are de facto ordered by frequency because shorter subwords come before longer ones, and shorter strings are more frequent than longer ones.
Do you have examples where applying the zipf transform doesn't work or tokenizers that are explicitly unordered?


small refactor todos

This is a big list of todos that came up during the refactor of the Go module.

[ ] Pluralize repeated fields in proto files: Some of the proto structs have repeated fields which are not plural (eg signature vs signatures).

[ ] Audit use of the name "Outgoing": The old code used words like OutgoingTx, OutgoingPool, etc. to refer to the thing that is now known as SendToEthereum. We now use the word OutgoingTx to refer to something completely different. We need to carefully find old uses of this term (requires in depth knowledge of the system to make sure it isn't the new use of the term) and change them to SendToEthereum.

[ ] Audit use of "Create" vs "Build" vs "New": Both the Create and Build prefixes generally indicate a method that does something somewhat complicated and stateful to make a new entity of some kind. We should standardize on one or the other. "New" usually indicates a simpler instantiation of a struct, which does not mutate other state, but in some places it is doing something more and we should replace it with Create or Build.

[ ] Nonce prefixing: We have many different nonces, including BatchNonce, SignerSetNonce, EventNonce, etc. Some data structures have two nonces. Mixing up nonces usually leads directly to a double spend error or something similarly dire, so we should prefix all nonce variables and fields with their type. Fixing this issue requires pretty in depth knowledge of what the different nonces are.

[ ] BridgeContract vs BridgeEthereumAddress: Make sure this is consistent everywhere.

[ ] Deprecated slash fraction params: We currently have different parameters for slashing of different types of OutgoingTxs. Unify them into one parameter (unless there is a need to actually slash different amounts).

[ ] Audit all Validate and ValidateBasic functions, especially on Msgs

[ ] Decide on, and likely remove MsgRequestBatch: This message allows anyone to request that a batch of SendToEthereums for a given token be created. By spamming this endpoint, an adversary could cause a large number of batches with only a small number of transactions in each batch to be created, which would not be profitable to submit, and would effectively halt the bridge. We have now moved to automatic batch creation, so this message should no longer be necessary.

[ ] Double check that any denoms passed in are validated correctly

[ ] Validation for ContractCallTx: ContractCallTxs are created by trusted external modules, calling a keeper method. We do not need to validate them for security reasons, but it might be nice to validate them for the convenience of calling module authors debugging.

[ ] Use bools in proto messages instead of magic values: We have many proto request messages that either return an array of many results, or only the latest result. Currently, the caller indicates they want the latest result by passing in a magic value like 0 or "". This has already caused programming errors in the short time it's been around. We should switch to an explicit "latest" boolean in the request.

[ ] Check if any iterators can be exited early: There are many iterators in the codebase that can be exited early by returning true. There may be some that could be exited early, but are not, wasting iterations.

[ ] Rename PendingSignerSetTxEthereumSignaturesRequest to UnsignedSignerSetTxsRequest: This is much more readable and accurate.

I'm also fine reverting to having separate latest routes.

I'm going to take a quick shot at using oneof on a PR for the magic value issue this afternoon. I think it might express our intention more clearly & am curious to see what it looks like, esp from a Rust perspective.

oneof makes things worse (at least for this use-case) -- I couldn't find a version on Saturday that even felt worth reviewing and think we should just use separate routes.


Update Join Together to 7.5.1

Thank you for the contribution. It was merged directly as a87adb739d3b7ff4ddf49306c9c322a52b1dd3ec to keep commit history cleaner. Your contribution is still credited to you.


FeatureRequest: Using of own keras-retinanet models & custom training for object-detection

Dear Moses, i did evaluate imageai and want to say great work.
So this is an feature-request:
The training of custom sets does result in a training-weights that can predict; I would like to see a feature to add a training for custom object-detection as well.
As well i like to ask - wether it is possible to use a custom-weight file from keras-retinanet or yolov3 or yolov3-tiny with your api?
Johannes

Kindly refer to this thread #8


Conda migration

After PR #549, DSSP installation is done via conda. Now the goal is to further clean the installation of deeprank2 and deploy it on conda.

[x] Migrate all deps to conda (PR #565)

[x] Start with the pytorch geom optional deps
[x] Then the rest
[x] Deploy pdb2sql on conda

Opened a PR on conda-forge (PR #25390)
Testing the package locally doesn't work

[x] Let's try to put >= everywhere in the deps and then only when necessary fix the versions
[x] Use the conda installation for both the CI build and the dockerfile

We use the PyPi release for now, but the idea is to not rely on pip dependencies anymore. We will have later two separate actions for testing the PyPI and the conda installations, or we will remove the PyPI installation entirely (we'll evaluate that).

(Not TODO anymore) Deploy on conda (after #565 will be merged and #570 will be solved)

Since the issue discussed in https://github.com/conda/conda-build/issues/532#issuecomment-1815442500 remains unresolved and there has been no activity on it for a year, we have decided to revert to using pip for installation. We will continue to use conda only for packages that specifically require it.

Since the issue discussed in conda/conda-build#532 remains unresolved and there has been no activity on it for a year, we have decided to revert to using pip for installation. We will continue to use conda only for packages that specifically require it.

Does this mean this issue can be closed? Or is there still some action needed from this issue?
Before closing, maybe it would make sense to also explain in this issue why poetry wouldn't work either. Just in case in the future someone wants to reconsider moving to either conda or poetry, then the information of why it doesn't presently work is all consolidated in one place.

Since the issue discussed in conda/conda-build#532 remains unresolved and there has been no activity on it for a year, we have decided to revert to using pip for installation. We will continue to use conda only for packages that specifically require it.

Does this mean this issue can be closed? Or is there still some action needed from this issue?

I am reverting things in #611

Before closing, maybe it would make sense to also explain in this issue why poetry wouldn't work either. Just in case in the future someone wants to reconsider moving to either conda or poetry, then the information of why it doesn't presently work is all consolidated in one place.

Good point, I'll add it here

A note about why we didn't used poetry.
Poetry is designed to work with pip dependencies, not conda packages. This is a significant limitation for this project since it relies on several conda packages from specific channels.
Our current setup (a yml file for conda dependencies and pip for the rest) is straightforward and easy to understand. Users familiar with conda and pip will find this approach intuitive.

@gcroci2 , had you looked at uv at all as an alternative to the conda migration? I just came across it (same developers as ruff) and thought that that might be a nice solution. I'm just not sure whether it will ultimately have the same issues as poetry does (I tried scanning through the issues, but couldn't see anything about it).

@gcroci2 , had you looked at uv at all as an alternative to the conda migration? I just came across it (same developers as ruff) and thought that that might be a nice solution. I'm just not sure whether it will ultimately have the same issues as poetry does (I tried scanning through the issues, but couldn't see anything about it).

Seems very interesting! We should definitely keep it in mind. But for this package, I don't think it solves the issue about the many conda deps we have (from what I've read it doesn't support conda installations) @DaniBodor


add loading to buttons

:tada: This PR is included in version 1.8.6 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Import #[repr(transparent)] docs from the Unstable book

… as the feature is ready for stabilization: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318

I don't think this text really fits into the reference, as it explains a lot of motivation and background rather than precisely and concisely stating what the attribute does. Certainly when I wrote it I had something like The Book or RBE in mind, not the reference.

Feature stabilization PR: https://github.com/rust-lang/rust/pull/51395
I agree that the subsections do not necessarily belong there as-is but I wasn’t sure what else to do, this PR is sort of a straw man.

I agree that this is not ready for integration into the reference. Adding more/confusing text is not necessarily better, even if it improves coverage.

Closing in favor of #389 since the RFC's contents don't translate to being in the reference directly that well.


core: Add test for AsyncCallbackManager context loss (relates to #23909)

Description:
This PR adds a failing test case to demonstrate the context loss issue in AsyncCallbackManager. The current implementation doesn't honor the run_inline attribute of callback handlers, leading to potential race conditions and ordering issues, especially when handlers depend on shared state or execution sequence.
Key points:

Issue with contextvars:

Since contextvars maintain context across asynchronous tasks within the same event loop.
While contextvars ensure state consistency, they don't reflect the order of execution or concurrency issues.
A test using only contextvars would pass even if tasks execute concurrently, masking the actual problem.

Test Case Approach:

Introduces shared_stack to capture the sequence of operations.
Uses three handlers: StateModifier and StateReader (both run_inline=True), and NonInlineHandler (run_inline=False).
Handlers manipulate a shared counter and append states to shared_stack.
Expected behavior: Sequential execution for inline handlers, resulting in a predictable state sequence.
Actual behavior: Concurrent execution leads to a non-deterministic order in shared_stack.

Effectiveness of the Approach:

shared_stack reveals concurrent execution issues that contextvars alone cannot detect.
Demonstrates the need to honor run_inline=True in AsyncCallbackManager.
Highlights potential problems in scenarios where handlers rely on sequential execution.

Outcome and Significance:

The test fails, proving that AsyncCallbackManager executes tasks concurrently even when they should be inline.
This failure effectively demonstrates the issue addressed by the proposed fix.
Emphasizes the importance of maintaining execution order for handlers dependent on shared state or sequential logic.

This test case clearly demonstrates the problem and justifies the proposed changes to AsyncCallbackManager and ensures it respects handlers' run_inline attribute.

Issue: This test case relates to the issue being addressed in PR #23909 (core: ensure run_inline is honored in AsyncCallback Handler)

Dependencies: No new dependencies are required. This PR only adds a test case.

Twitter handle: @parambharat

@eyurtsev

@parambharat this should be fine -- i can take over, would you make the 2nd PR that updates the callback dispatcher?

hi @eyurtsev . Just checking in. Any update on merging this here ?

PR merged


Python README needs Mac/Linux instructions

See #29

Linux comes preinstalled with Python....but still I will put in a line.

didn't see the related pull requests. see #48

Cool well done @trqx


chore: bump friendsofphp/php-cs-fixer from 2 => 3

bump php from >=7.2 to >=7.2.5 for this

https://github.com/omines/datatables-bundle/pull/228

Version 2 of this is blocking some symfony6 components from installing in dev environment. (Example: symfony/options-resolver)
https://packagist.org/packages/friendsofphp/php-cs-fixer#v2.19.3


unavailable package on clean install

I started with a clean git clone and get the following message.
Error (use-package): Failed to install pcmpl-git: Package ‘pcmpl-git’ is unavailable

Thanks! Can you tell me what version of Emacs you're using?

Looking more closely I think I can actually remove that package. pcmpl-args.el seems like it provides all the necessary git support.

Works fine now.
Now I have no excuses to start work.


Bug Fix: Webhook secret stored incorrectly in state

Addressing #171 where the webhook secret set in Terraform makes signatures not match.
Before fix:
--- FAIL: TestAccGithubRepositoryWebhook_importSecret (9.38s)
    testing.go:568: Step 1 error: ImportStateVerify attributes not equivalent. Difference is shown below. Top is actual, bottom is expected.

        (map[string]string) (len=1) {
         (string) (len=22) "configuration.0.secret": (string) (len=8) "********"
        }

        (map[string]string) (len=1) {
         (string) (len=22) "configuration.0.secret": (string) (len=18) "RandomSecretString"
        }

After fix:
=== RUN   TestAccGithubRepositoryWebhook_importSecret
=== PAUSE TestAccGithubRepositoryWebhook_importSecret
=== CONT  TestAccGithubRepositoryWebhook_importSecret
--- PASS: TestAccGithubRepositoryWebhook_importSecret (9.66s)
PASS

Ah, this explains why terraform screwed up all of our organizations hook secrets! Can we get this merged....

Hope this get reviewed and merged soon :rocket:

Hope this get merged ASAP. we have to apply the patch manually currently, which is not very nice.


Icons

It's not an issue but a question.
Where did you get the icons?
I'm looking everywhere to find different icons.
thanks!

I am wondering the same thing
where you able to solve it?

Not yet

Ensure fontawesome = true in your config file, then you can go to https://fontawesome.com/search?s=regular&f=classic&o=r.
Click the icon you want and add the icon names. For example, fa-regular fa-image to use the image icon.


1.7 pls

title as follows
making a 1.9 -> 1.7 protocol hack but my tables of differences are too big to maintain manually :[

Unless you wish to add support yourself there is no plans for us to add this.
AFAIK, it's just making burger possibly use an older version, unsure.

Burger kinda works with 1.7.10, but some of the toppings don't work.  It looks like the packetinstructions topping works, though, so you should be able to just tell it to only generate packetinstructions.  Except that looks like what's already being done - so I'm not sure why it's not working.
It seems like the blocks topping is the broken one, which breaks a few other toppings (items and recipes depend upon it).  But the toppings PAaaS uses are fine...

OK, I checked - 1.7 support isn't there for all versions (packets fails on a few and I'm getting JSON format errors for others), but it does work for 1.7.10 and a few of the versions before it (but not all of the 1.7.x versions).  It probably would be best to add support for 1.7.10 by changing the date used for comparison to<PHONE_NUMBER>000L, since that seems to work well enough.  I'll try to figure out what's wrong with burger.
It does seem like version doesn't work on 1.7.10 annoyingly.  But the packets list is there, so that's probably good enough for the moment for PAaaS.


[glide] Update m3metrics dependency

Pull in latest m3metrics revision to support max buffer capacities in the buffered encoder pools.
cc @xichen2020

Coverage remained the same at 94.039% when pulling 78f0f9e733f5b87abff2eb72c477cfdad9ab6257 on jeromefroe/update-m3metrics-to-list into 2800ce19d53813f96b65376fb29256c9f19f4fd6 on master.

Coverage remained the same at 94.039% when pulling 2fd45e6bb54c5892c10b7cd26395d68a43e69f44 on jeromefroe/update-m3metrics-to-list into 2800ce19d53813f96b65376fb29256c9f19f4fd6 on master.


Bazel fail executing command aar_native_libs_zip_creator.exe,aar_embedded_jars_extractor.exe, aar_resources_extractor.exe

INFO: Analyzed target //mediapipe/examples/android/src/java/com/google/mediapipe/apps/aar_example:mediapipe_pose_tracking.aar (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: C:/users/Username/_bazel_chai1/ojr2u6ty/external/maven/BUILD:62:11: Filtering AAR native libs by architecture failed: (Exit 2): aar_native_libs_zip_creator.exe failed: error executing command bazel-out/host/bin/external/bazel_tools/tools/android/aar_native_libs_zip_creator.exe --input_aar ... (remaining 5 argument(s) skipped)
/usr/bin/python: can't open file '/c/users/chai1/_bazel_chai1/ojr2u6ty/execroot/mediapipe/C:\Users\Username_bazel_chai1\ojr2u6ty\execroot\mediapipe\bazel-out\host\bin\external\bazel_tools\tools\android\aar_native_libs_zip_creator.zip': [Errno 2] No such file or directory
Target //mediapipe/examples/android/src/java/com/google/mediapipe/apps/aar_example:mediapipe_pose_tracking.aar failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.865s, Critical Path: 0.39s
INFO: 129 processes: 129 internal.
FAILED: Build did NOT complete successfully
Im trying to run mediapipe with android using this command
"bazel build --action_env PYTHON_BIN_PATH=C:\Users\Username\AppData\Local\Programs\Python\Python38\python.exe -c opt --strip=ALWAYS --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --fat_apk_cpu=arm64-v8a,armeabi-v7a //mediapipe/examples/android/src/java/com/google/mediapipe/apps/aar_example:mediapipe_pose_tracking.aar"
but the error show that, it unable to run the .exe file inside the folder and after I manually extracted, another .exe file facing the same problem again.
Anyone can help me with this error?

Hi @sgowroji, thanks for replying, here's the step i went through
1.)I am using guide from https://google.github.io/mediapipe/getting_started/android_archive_library.html to create a Mediapipe AAR file. I run this on PowerShell
2.) When running step 2 from the given,
i uses bazel build --action_env PYTHON_BIN_PATH=C:\Users\Username\AppData\Local\Programs\Python\Python38\python.exe -c opt --strip=ALWAYS --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --fat_apk_cpu=arm64-v8a,armeabi-v7a //mediapipe/examples/android/src/java/com/google/mediapipe/apps/aar_example:mediapipe_pose_tracking.aar
3.) follow the step given to resolve error #724 https://github.com/google/mediapipe/issues/724#issue-622686030
Then this bazel fail command prompt.
Thanks for

As we mentioned in https://google.github.io/mediapipe/getting_started/install#installing-on-windows, MediaPipe doesn't support building its Android apps on native Windows because of the limited bazel support for Android on native Windows. Please try WSL instead. You can find the instructions at https://google.github.io/mediapipe/getting_started/install#installing-on-windows-subsystem-for-linux-wsl.

Hi @newbie7991, Have a look at the comment .

As we mentioned in https://google.github.io/mediapipe/getting_started/install#installing-on-windows, MediaPipe doesn't support building its Android apps on native Windows because of the limited bazel support for Android on native Windows. Please try WSL instead. You can find the instructions at https://google.github.io/mediapipe/getting_started/install#installing-on-windows-subsystem-for-linux-wsl.

thank you for the answer....

Thanks @sgowroji


Confirm semantics support (with tests)

@QuncCccccc
This is looks like accidental duplicate of https://github.com/flutter/flutter/issues/127617

Oops! I think it is because I clicked the "convert to issue" button twice🤣Sorry about that! Closing this.


Feature request: Add "Did you mean X?"

When misspelling a property in an object type, I get such an error right now:
Error: 1 validation issue(s)

  Issue #0: unrecognized_keys at
  Unrecognized key(s) in object: 'errorrFormat'

    at new ZodError (/root/code/runtime-validation/node_modules/zod/src/ZodError.ts:124:5)

It would be great, if a "Did you mean errorFormat?" could be shown.
In Prisma Client, we're using js-levenshtein for that purpose (after comparing all the 500 levenshtein implementations on NPM 😄  )

Hey Tim - excited to see you're using Zod!
This feature might be a little too small to warrant adding Zod's first dependency :) But I'll see if I can copy/paste in a minimal Levenshtein implementation without increasing the bundle size too much. 🤙


Explorer simple-git, as alternative .git interface

simple-git, seems to essentially do what we already do. The only difference I have observed, is that simple-git seems to perform more consistently. In conclusion, switching to simple-git gives very little value, and does not seem worth the effort.


LCP-protected EPUBs fail to load because of LSD-related error

Test with any of the 3 protected publications from:
https://www.edrlab.org/readium-lcp/testing-readium-lcp-compliant-devices/
(LCP passphrase "edrlab rocks")
Direct LCP license links:

https://www.edrlab.org/public/readium-lcp/wasteland.lcpl
https://www.edrlab.org/public/readium-lcp/accepub3.lcpl
https://www.edrlab.org/public/readium-lcp/haruko.lcpl

Wasteland is a small publication, so I am attaching it here.
wasteland_lcp.zip
The following error is raised when attempting to open wasteland.lcpl.epub directly (i.e. not via the LCP license wasteland.lcpl):
[2] ### LCP publication
[2] TypeError: Cannot read property 'lsd' of undefined
[2]     at LcpManager.<anonymous> (/Volumes/500GB/Code/readium-desktop/dist/main.js:5619:89)
[2]     at Generator.next (<anonymous>)
[2]     at /Volumes/500GB/Code/readium-desktop/dist/main.js:5490:71
[2]     at new Promise (<anonymous>)
[2]     at module.exports../src/main/services/lcp.ts.__awaiter (/Volumes/500GB/Code/readium-desktop/dist/main.js:5486:12)
[2]     at LcpManager.getLsdStatus (/Volumes/500GB/Code/readium-desktop/dist/main.js:5617:16)
[2]     at runCallEffect (/Volumes/500GB/Code/readium-desktop/node_modules/redux-saga/lib/internal/proc.js:524:19)
[2]     at runEffect (/Volumes/500GB/Code/readium-desktop/node_modules/redux-saga/lib/internal/proc.js:446:402)
[2]     at next (/Volumes/500GB/Code/readium-desktop/node_modules/redux-saga/lib/internal/proc.js:326:9)
[2]     at currCb (/Volumes/500GB/Code/readium-desktop/node_modules/redux-saga/lib/internal/proc.js:399:7)
[2]     at process._tickCallback (internal/process/next_tick.js:68:7)
[2] ### action type STREAMER_PUBLICATION_OPEN_ERROR
[2] ### action type READER_OPEN_ERROR

By rollback-ing the Git revision I managed to identify the culprit to:
https://github.com/readium/readium-desktop/commit/dedaae921ec3212ad361972bc91a0f8aaddca0dd
In other words, the commit immediately before in the history, works:
https://github.com/readium/readium-desktop/commit/937de9446e01ba9de2c0bb754d41e17669751110
(this makes sense, as there is a new check when attempting to load a publication)

I suspect that publicationDocument.lcp is undefined when an LCP-protected publication is not opened from an LCPL license, so publicationDocument.lcp.lsd.statusUrl fails with an exception.
https://github.com/readium/readium-desktop/blob/42a6ab3efa20879db9f8f4b6503e15551b93df19/src/main/services/lcp.ts#L229-L236

The second test is to open the LCPL license, let the app download the encrypted EPUB (and inject the META-INF/license.lcpl) ... then the book loads fine the first time. However subsequent times fail with LICENSE_SIGNATURE_DATE_INVALID / 111, which indicates some error in how the LCP license is stored in the database. In fact, I can of course copy the book.epub from the private app storage, and attempt to load the copied EPUB => this results in the same TypeError: Cannot read property 'lsd' of undefined.
https://github.com/readium/readium-desktop/blob/42a6ab3efa20879db9f8f4b6503e15551b93df19/src/main/services/lcp.ts#L95-L97

Regarding the 111 error, this actually seems legit, because the following chain of URLs does return a different LCPL from the original:
https://www.edrlab.org/public/readium-lcp/wasteland.lcpl
=>
https://lsd-prod.edrlab.org/licenses/9679f657-4a90-4e39-8f35-63784e269e6c/status
=>
https://front-prod.edrlab.org/api/v1/licenses/9679f657-4a90-4e39-8f35-63784e269e6c
(in fact, requesting the above URL multiple times never returns the same LCPL license ... not sure if this is a feature or a bug)

But, the 111 should not happen in Thorium with Wasteland, because the LSD does not announce the availability of a more recent LCP license (so the original LCP license should always be in use). To be verified.


Where is the source code of the unit tests written by developers?

Hello, I want to know where exactly does dj4 store the unit tests written by the developers to uncover the bugs?
Thanks.

You can determine the path to the developer-written tests using the defects4j export command in the working directory of a checked-out project version. The property you are interested in is dir.src.tests.


docs(js/README): fix link typo to i18n

Coverage remained the same at 98.346% when pulling 667c3912ac219db9598d7e69c3b11ef5fa76a61e on Hotell:patch-1 into 71116a8f417668e068e71a68449164f32d9702e5 on mxstbr:master.

Woah, good catch, thanks! :+1:


Multithreadding on windows dosent work.

When running a GA on a windows box there are issues with the starmap methods not working on windows.

axelrod_dojo/algorithms/genetic_algorithm.py:67

For this to be helpful could you out some of the stack trace here.

This seems to have been fixed for the windows issue.

Ok, thanks I'll close this.


pghoard: When restoring try to fetch a file from the archive if local…

… invalid
We now catch HttpResponse errors as well and properly try fetching the data
from the object storage. Add a unit test for this case as well.

This requires rebasing (and re-adding the reverted commit in this branch)


Add unit testing

Jest would be a strong option

Closing this for now as I have no intention to work on it shortly.