Collect code from function rather than context

When running TPC-H benchmarks I find that I don't get code samples from the polars/duckdb benchmarks.  This is a shame, I'd like to see the code that we run here.  (although to be clear, it's not a big deal).
When thinking about it though, this makes sense.  We don't capture the code of the function itself, just the context from where it is called.  This makes sense for most of Dask because there are many different functions all being called for a given compute call.  It doesn't make sense to try to capture that code.  For coiled.function and client.submit more generally though, it might make sense to capture not just the context, but also the source code of the submitted function.
I can imagine a world where Dask identifies this case, perhaps by conditioning on a computation not having any code samples, and there being only one function that is being called in all tasks of that computation.  We could then inspect the task, pick out the function, and share that code instead.  This is only one option for this problem; I suspect that there are others.  My guess is that this would add some code complexity, but in an isolated way, and that this would be relatively cheap (the checks are cheap).
No pressure or urgency.  This would be nice, but it's not a big deal.  I'm guessing that this is mostly a question for @fjetter and maybe @crusaderky .

Not sure if this helps or not, but I'll mention that we have coiled.span(cluster, callstack) to capture code outside of the context of dask. This is currently used for coiled run:
https://github.com/coiled/platform/blob/e2755494a1c77184b58ce6e5da2d76610e66a2b5/python-api/coiled/cli/run.py#L472

Oh cool, so maybe we do the same thing for coiled.function generally?  We add the source-code of the function we're decorating?
I think it probably still makes sense to include the callstack if it's available.  We just want to add an extra internal layer.  Is this easy to do?

Not sure I understood the request here.
Are you asking that, when the user calls client.submit, you want dask to figure out if the passed callable is a generic library function (numpy, scipy, etc.) or user-defined code, and add a code snippet to the span only in the latter case?
How do you suggest telling them apart? Check if the path to the module contains /site-packages/?

That's not what I'm suggesting, no.  I'm suggesting that for Coiled function we include the code of the wrapped function in the code returned to Coiled, rather than just the context from which it is called.  From what I can tell, the suggestion from @ntabris should work well.

For broader motivation / context, if you take a look at any of the polars/duckdb tests they look like this:
https://cloud.coiled.io/clusters/292431/information?account=dask-benchmarks

Similarly for Prefect we get only

In these cases the context isn't very helpful, but we might be able to get some good insight from the function we're wrapping instead, whatever it is.

Oh sorry, the second example was for joblib.  Prefect jobs are similarly opaque though.


Create styles.css

Create styles.css for the homepage and general styles

The general styles.css is created

The styles.css is merged to develop branch


Support using alluxio default block size when UFS is hadoop-compatible object storage filesystem

Background
Alluxio has 2 ways to use object storage as UFS.

Alluxio native interface: alluxio.underfs.ObjectUnderFileSystem
Hadoop-compatible FileSystem interface: org.apache.hadoop.fs.FileSystem

About block size, in ObjectUnderFileSystem, it is default using alluxio default block size (alluxio.user.block.size.bytes.default). In hadoop filesystem case, it is depend on different FileSystem implementation. For example, S3AFileSystem take configuration 'fs.s3a.block.size' as blocksize.
So when i use hadoop filesystem to access S3, i need configure fs.s3a.block.size not exact alluxio.user.block.size.bytes.default .
This patch allows user config block size by alluxio.user.block.size.bytes.default even using S3AFileSystem as UFS.
Config
in S3A case, fs.s3a.block.size=1, 1 is magic number block size. which hint Alluxio to use alluxio.user.block.size.bytes.default as default block size.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7003/
Test FAILed.

Since you've signed the CLA in https://github.com/Alluxio/alluxio/pull/10500 I'll remove the label here

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-PR-Builder/9427/
Test FAILed.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-PR-Builder-jdk11/34/
Test FAILed.

Can one of the admins verify this patch?


Update code for Python 3 compatibility, and miscellaneous other improvements.

This PR updates the extension from Python 2 to 3. It is not expected to continue to work with Python 2. With Slicer moving to Python 3, now is the time to make this change.
Several incidental improvements and bug-fixes are included in this PR.

Hi @JEHoctor Thank you so much for this PR, could you change your commit messages to adhere to the ITK contribution guide? You did this with 9e6c12681efa9bf54fb44d6572e85fc2106a2b1e but not with the rest.
More info here re.  Clément Mirabel's commit message remains unaltered with the tag "FIX" instead of "BUG".

@JEHoctor Much appreciated, thanks!


Clarify ChanServ usage and Flags

The Channel Modes guide mentions ChanServ flags, but not what they mean and how to use them. There is also no info anywhere in the guides about using ChanServ beyond registering a channel.

made an attempt at this. submitted in the hope it is useful!

Would this document also include how to find who are ops on a channel? Ref: https://github.com/Libera-Chat/libera-chat.github.io/pull/135/files#r692104401

Would this document also include how to find who are ops on a channel? Ref: https://github.com/Libera-Chat/libera-chat.github.io/pull/135/files#r692104401

No, this is for people configuring their channel. Finding ops is covered here: https://libera.chat/guides/faq#how-do-i-get-unbanned-or-unquieted

The current https://libera.chat/guides/creatingchannels was written quickly and should be rewritten, it'd ideally include the above information.


Signal Telemetry for Targeted Signals

Description
Targeted signals present a new challenge to tracking signal metrics since non-self-targeted signals will not come back (if the service has targeting support). This case motivates a more holistic investigation into signal monitoring and if targeted support should change the way we do things currently.
Summary of Changes
We now look at all incoming signals to see if they are coming in sequential order. If a signal sequence number(s) is skipped, we log a 'SignalLost' event and continue to monitor for both new signals and out of sequence signals. Once we receive an out of order signal (previously logged as lost), we log a 'SignalOutOfOrder' event.
The sliding 'signal tracking window' is defined by [minimumSignalSequenceNumber, trackingSignalSequenceNumber]. If a targeted signal is sent, the local signal sequence is now broken, so we will ignore all previously sent outbound signals (minimumSignalSequenceNumber = trackingSignalSequenceNumber = 'nextSignalExpected'). We do a similar 'tracking window reset' on reconnect, since we might have missed signals in flight while disconnected.
We still log the roundtrip time for every 100th broadcast signal (broadcastSignalSequenceNumber was added to avoid degenerate case of attempting to track any targeted signal RTT).

It is a bit more complicated, but I think we want to be more incremental. I was not expecting to see a change to ISignalEnvelope in here - and I'll need to think about the implications. You could leave this PR and do one that just what is needed for broadcast since that is all we support right now. Then this is the follow up. Also, tests!, we want tests.

I've opened a PR that updates telemetry just for broadcast: https://github.com/microsoft/FluidFramework/pull/22033. I'll leave this one as a draft.


The stackStr in test.result.errors has ANSI color codes

Describe the bug
When creating a custom reporter, the test.result.errors[index].stack and test.result.errors[index].stackStr consist of some ANSI color codes (possibly to show color when logged in the console). However, this affects all other custom reporters that do not want to log to the console, for instance, the one I shared in the link above.
Reproduction
TLDR;
Check out this PR.
Reproduction
When using the GithubReporter from GithubReporter.ts, when expect failed in a test with .not.toBeCalled(), there were ANSI characters in the stack trace, whereas when the expect failed in a test with expect(a).toBe(b) there were no ANSI color codes in the stack trace.
P.S. this is reproducible only on the sample-test branch of the repository, because there is a regex to filter out ANSI codes from the stack trace on the main branch.
import { defineConfig } from 'vitest/config';
// import { GithubReporter } from 'vitest-github-action';
import { GithubReporter } from './src';

export default defineConfig({
    test: {
        reporters: process.env.GITHUB_ACTIONS
            ? ['default', new GithubReporter()]
            : 'default',
    },
});

Test file that has ANSI colors in stack trace when there's an error:
import {beforeEach, describe, expect, test, vi} from 'vitest';

let sum: () => void;

describe('Given sum() exists', () => {
	beforeEach(() => {
		sum = vi.fn();
	});

	describe('When sum() is called', () => {
		beforeEach(() => {
			sum();
		});

		test('sum() should be called', () => {
			expect(sum).toBeCalled();
		});

		test('sum() should not be called', () => {
			expect(sum).not.toBeCalled();
		});
	});
});

Test file that does not have ANSI colors in the stack trace when there's an error:
import {beforeEach, describe, expect, test} from 'vitest';
import sum from './sum';

function sum(a: number, b: number) {
	return a + b;
}

let val: number;

describe('Given sum() was called', () => {
	describe('When the arguments are 1 and 1', () => {
		beforeEach(() => {
			val = sum(1, 1);
		});

		// Passing test
		test('Then the sum should be 2', () => {
			expect(val).toBe(2);
		});

		// Failing test
		test('Then the sum should be 3', () => {
			expect(val).toBe(3);
		});
	});
});

What is weird is that both of these actually show colors when these errors are logged in the console. I'm not sure if that's the vitest reporter, because seemingly, the colors (or colorful error messages, as in the image below) are not there in the stack trace logged in sum.test.ts.

System Info
System:
    OS: Linux 5.19 Manjaro Linux
    CPU: (16) x64 AMD Ryzen 7 4800H with Radeon Graphics
    Memory: 5.55 GB / 14.99 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 19.1.0 - ~/.nvm/versions/node/v19.1.0/bin/node
    npm: 6.14.15 - ~/Documents/Repos/dyte/web-core/node_modules/.bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 109.0.1
  npmPackages:
    @vitest/coverage-c8: ^0.28.3 => 0.28.3
    vite: 3.0.1 => 3.0.1
    vitest: ^0.28.5 => 0.28.5

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Seems like we need to add more checks for displaying colors. I removed picocolors in #2828 (which will probably be extracted into its own PR), and we can do that there.

Colors are disabled if GITHUB_ACTIONS is present


MM-47078 : Migrate "components/suggestion/modal_suggestion_list.jsx" to Typescript

Summary
Migrate modal_duggestion_list.jsx to typescript
Ticket Link
Fixes https://github.com/mattermost/mattermost-server/issues/21091
Fixes https://mattermost.atlassian.net/browse/MM-47078
Related Pull Requests
None
Screenshots
NA
Release Note
NONE

Hello @AbhinavVihan,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

E2E tests not automatically triggered, because PR has no approval yet. Please ask a developer to review and then try again to attach the QA label.

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

@hmhealey can you please take over the review of this pr ? :)

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

@hmhealey, can you please take a look :)
Thankyou

Sorry about the delay with this. I remember being a bit confused about why we switched reviewers on this, and then I lost track of it after that. I'll take another look at this shortly and dismiss the outdated reviews

/e2e-test

Successfully triggered E2E testing!
GitLab pipeline | Test dashboard

@jgilliam17 This is ready for QA review

/update-branch

I'm going to try updating the branch to see if that fixes the issue with the upload-s3 job in CircleCI. I'm not sure if that's just an intermittent failure or if it's related to us updating some S3 credentials recently

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

Removing the "stale" label since this is waiting on us

@jgilliam17 its ready for QA review

/e2e-test

/e2e-test

Successfully triggered E2E testing!
GitLab pipeline | Test dashboard

/e2e-test

Successfully triggered E2E testing!
GitLab pipeline | Test dashboard

Thanks @AbhinavVihan - apologies for delay in getting to this PR
Tested, looks good to merge
E2E report - no PR related failures.

@M-ZubairAhmed I see that you previously commented/requested  changes. Let me know if your concerns were addressed, if yes , please merge - thanks 🙂

Thanks again for the PR, @AbhinavVihan! Glad to have this in


Update Release Automation workflows to deploy a new release to the AWS Pass Demo instance

Temporarily, we can probably update the release workflow of pass-docker to include a deploy to AWS. In the standard release procedure, pass-docker will be completed last, at which point all necessary docker images will have been created, or will be created within pass-docker. Otherwise, there are several issues that need work before we can have a one-release-to-rule-them-all situation


User group authorizations

As an administrator I want to be able to manage groups, add users and be able to give the whole group authorizations in the ZITADEL console, so I do not have to manage it for all users separately.
### Acceptance Criteria
- [ ] Groups CRUD, create, update, delete, get
- [ ] Search groups by context (instance, organization, user)
- [ ] Group does have an id and a name
- [ ] I am able to add a user and remove a user from a group
- [ ] I am able to list all users from a group
- [ ] I am able to add an authorization/user grant (project, and roles) to a group
- [ ] I am able to remove an authorization/user grant from a group
- [ ] I am able to get a list of authorizations by a users and I see the group
- [ ] When a user authenticates the merged authorizations are taken into account.
- [ ] I am able to get the group authorizations in the tokens and on the userinfo

More Information:
Merged Authorization: The user does have a "personal" user grant with the role "Admin", and the user is in the group "developers" which has the role "User". The users will have both roles "Admin" and "User" because they are merged.

I would like to also add that groups should be hierarchical by nature.
also another name for this would be "organization units"

+1 for groups, I have SAML application that requires Group attribute/s

Really needed feature for us. For now as workaround we planed to use Pulumi/Terraform and there we will create logic for "groups" of users.

@ahmednfwela I also know the term "organizoation unit" but i think it could be a little bit misleading because ZITADEL already has "Organizations". So i think "Groups" is the better term, but thats just my opinion.

I wouldn't use  "organization units", Group is an expected and extremely common naming for such feature in the context of IAM.

It's unclear whether group authorization for machine (service-account) users is in the scope. Potential group authz use-cases for service-accounts:

Consistent and simplified management of permissions especially as the number of machine users grows
In microservices environments, managing permissions of inter-service communication is simplified through group authz

@yordis thanks in particular for the Auth0 link; authz is indeed a complicated area and yes I'm still learning. The specific usecases we're trying to address:

Machines (eg IoT devices) accessing resources via, say, REST API
Human users accessing resources using a CLI

Here I believe long-lived service-account credentials, as opposed to JWT token with expiration, would be more suitable. The resource server (actually the API Gateway) would first derive/fetch authorization metadata from IAM server (ZITADEL), and decide whether to allow / deny the requests.
We're yet to implement the entire e2e process for individual machine user. Once we do it for an individual machine, I believe it makes more sense to group the machines, and assign permissions to groups instead of individual machine.

I think it would be beneficial to be able to retrieve the group memberships of a user in a claim when requesting an additional scope. Even when there is no authorization applied.
This could be a good addition to be able to perform AuthZ in a next step to be able to decide if a user is allowed to access some resources based on its assigned groups.
We currently put the user's groups for federated users as group claim in access and id token by fetching them from the Entra ID graph API. Based on the groups we than can take authorization decisions in istio. To have the same also for local users with Zitadel groups is something we would really need to go further with authorization.
I have an idea that this scenario might be extended by mapping groups from Entra ID on Zitadel groups and perform authorization based on group memberships in Zitadel.

We need this setup:
Org
- Team 1
- -- User 1
- -- User 2
- Team 2
- -- User 1 (same as in Team 1)
- -- User 3

User can be member of multiple teams/groups, and possibly multiple orgs.

Would this feature be available by 2024 ?

Would this feature be available by 2024 ?

no this will not be available this year


Don't ignore color argument in confirm dialog

This PR changes the survey.confirm API to use the user supplied color for the hint and the answer.

You are clearly quicker than I am. I was still wondering whether to use the focus color or response color for the selection hint. Thanks!

I figured that staying consistent across behaviours matters more!
Plus, I think it's neat how the color doesn't change upon submission.

Agreed, it's really neat. Regarding the new filter, you may want to specify wrapio >= 0.3.5 as a requirement.

Great catch! Sheesh thanks so much for the contributions 😌


Is there a way to override use_enum_values?

Bug description
_PrismaModel uses config use_enum_values and causes pyright to complain about typing rightfully
It's expecting a enum where you'd use .value to get the string but due to the config used the type is actually a string literal.
Checkout the issue here for more context:
https://github.com/pydantic/pydantic/issues/6565

My UserGroup has the following type:
class UserGroup(StrEnum):
    USER = 'USER'
    ADMIN = 'ADMIN'
    MEMBER = 'MEMBER'

But when I am retrieving these groups from Prisma, I am getting a str back instead of an ENUM.
type(result.groups[0])
<class 'str'>


Update camera_to_hls

Updates the deps.
Adjusts the code to new Membrane Core and new HLS plugin

Noticed this pull request after making similar changes myself.
Just learned about Membrane today, works pretty much out of the box. Amazing product! Reminds me of the early erlyvideo days.  🙂

Closing in favour of #239  and #241


Error in union with length constraint

export const feedbackSchema = type({
  // ParseError: Key $ is not valid on maxLength schema
  contact: "string.email | string == 0",
});

Fixed as of 2.0.0-rc.29


Question - Joining cluster after member host down

It appears that the feature for dynamic cluster member was removed in version 1.41. So in a normal setup where each cluster node is on a different host, if one cluster host goes down due to some hardware issue (i.e. we cannot bring up the process on the same host within a reasonable amount of time), does that mean it is not possible to bring up the process on a different host to join the cluster to restore the quorum?

@kchgoh It is possible if host names (DNS) or driver names are used instead of IP addresses. Just bring another host and use the same DNS name/driver name as the one that has issues. When using DNS names you'll need to update your DNS to point to a different IP address.
See also https://github.com/real-logic/aeron/wiki/Name-Resolution.

Thanks for the quick reply! From the wiki it will auto resolve the DNS name again on interval so it should be fine for this scenario, good to know that.
The README file may need to be updated as it still mentions the Dynamic Membership feature. Though it would be nice if a similar feature will become available again in the future.
Really appreciate the great work!


Add training.egi.eu VO for CESNET-MCC

Hi @sebastian-luna-valero,
I think that the value auto_allocated_network for private network will not work.


Connect-MicrosoftTeams using -AccessTokens fails (MicrosoftTeams PS Module v3.1.1 and v4.0.0)

When trying to Connect to Microsoft Teams, we should be able to use a delegated APPID and ClientSecret to gain both a graphToken, and a teamsToken. The token retrieval works.. Unfortunately the Connect-MicrosoftTeams -AccessTokens switch fails to use those tokens to successfully instigate a PS Session.
Microsoft's documentation: https://docs.microsoft.com/en-us/powershell/module/teams/connect-microsoftteams?view=teams-ps#example-4-connect-to-microsoftteams-using-accesstokens
PREP WORK:
$graphResource = "https://graph.microsoft.com/"
$graphtokenBody = @{
   Grant_Type    = "client_credentials"
   Scope         = "https://graph.microsoft.com/.default"
   Client_Id     = $ApplicationID
   Client_Secret = $clientSecret
}
$graphToken = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token" -Method POST -Body $graphtokenBody -Verbose | Select-Object -ExpandProperty Access_Token

$teamsResource = "https://api.interfaces.records.teams.microsoft.com"
$teamstokenBody = @{
   Grant_Type    = "client_credentials"
   Scope         = "48ac35b8-9aa8-4d74-927d-1f4a14a0b239/.default"
   Client_Id     = $ApplicationID
   Client_Secret = $clientSecret

}
$teamsToken = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token" -Method POST -Body $teamstokenBody -UseBasicParsing -Verbose | Select-Object -ExpandProperty Access_Token

Confirming the Tokens look ok... using JWTDetails Module:
$($graphToken | Get-JWTDetails).Roles | sort
AppCatalog.Read.All
AppCatalog.ReadWrite.All
Directory.Read.All
Directory.ReadWrite.All
Group.Read.All
Group.ReadWrite.All
People.Read.All
Team.ReadBasic.All
TeamSettings.Read.All
User.Read.All

$($teamsToken | Get-JWTDetails).Roles | sort
application_access
application_access_custom_sba_appliance

Trying to Connect:
Method 1, passing the Access tokens in as an array, matching microsoft's documentation here:
Connect-MicrosoftTeams -AccessTokens @($graphToken, $teamsToken) -Verbose
Connect-MicrosoftTeams : Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'AccessTokens'. Specified method is not supported.
At line:1 char:38
+ ... nect-MicrosoftTeams -AccessTokens @($graphToken, $teamsToken) -Verbos ...
+                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Connect-MicrosoftTeams], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgument,Microsoft.TeamsCmdlets.Powershell.Connect.ConnectMicrosoftTeams

Method 2, passing an array of tokens as "strings":
Connect-MicrosoftTeams -AccessTokens @("$graphToken", "$teamsToken") -Verbose
VERBOSE: Performing the operation "Connect-MicrosoftTeams" on target "Establishing a PowerShell session connected to the environment.".
Connect-MicrosoftTeams : Object reference not set to an instance of an object.
At line:1 char:1
+ Connect-MicrosoftTeams -AccessTokens @("$graphToken", "$teamsToken")  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   + CategoryInfo          : AuthenticationError: (:) [Connect-MicrosoftTeams], NullReferenceException
   + FullyQualifiedErrorId : Connect-MicrosoftTeams,Microsoft.TeamsCmdlets.Powershell.Connect.ConnectMicrosoftTeams

Connect-MicrosoftTeams : Object reference not set to an instance of an object.
At line:1 char:1
+ Connect-MicrosoftTeams -AccessTokens @("$graphToken", "$teamsToken")  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   + CategoryInfo          : NotSpecified: (:) [Connect-MicrosoftTeams], NullReferenceException
   + FullyQualifiedErrorId : System.NullReferenceException,Microsoft.TeamsCmdlets.Powershell.Connect.

Method 3, attempting to force the token type as bearer, in strings:
Connect-MicrosoftTeams -AccessTokens @("bearer $graphToken", "bearer $teamsToken") -Verbose
VERBOSE: Performing the operation "Connect-MicrosoftTeams" on target "Establishing a PowerShell session connected to the environment.".
Connect-MicrosoftTeams : IDX14102: Unable to decode the header 'System.String' as Base64Url encoded string. jwtEncodedString: 'System.String'.
At line:1 char:1
+ Connect-MicrosoftTeams -AccessTokens @("bearer $graphToken", "bearer  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : AuthenticationError: (:) [Connect-MicrosoftTeams], ArgumentException
    + FullyQualifiedErrorId : Connect-MicrosoftTeams,Microsoft.TeamsCmdlets.Powershell.Connect.ConnectMicrosoftTeams

Connect-MicrosoftTeams : Invalid length for a Base-64 char array or string.
At line:1 char:1
+ Connect-MicrosoftTeams -AccessTokens @("bearer $graphToken", "bearer  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : AuthenticationError: (:) [Connect-MicrosoftTeams], FormatException
    + FullyQualifiedErrorId : Connect-MicrosoftTeams,Microsoft.TeamsCmdlets.Powershell.Connect.ConnectMicrosoftTeams

Connect-MicrosoftTeams : Object reference not set to an instance of an object.
At line:1 char:1
+ Connect-MicrosoftTeams -AccessTokens @("bearer $graphToken", "bearer  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-MicrosoftTeams], NullReferenceException
    + FullyQualifiedErrorId : System.NullReferenceException,Microsoft.TeamsCmdlets.Powershell.Connect.ConnectMicrosoftTeams`

Method 4, using an impersonation account:
$ImpersonationUser = $(Get-MSGraphUser -Identity $ImpersonationUPN)
VERBOSE: GET https://graph.microsoft.com/v1.0/users?$filter=userPrincipalName in ('automation@TENANTNAME.onmicrosoft.com')&$select=id,userPrincipalName,displayName,mobilePhone with 0-byte payload
VERBOSE: received -1-byte response of content type application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8

$ImpersonationUser | Format-Table

id                                   userPrincipalName                          displayName                                mobilePhone
--                                   -----------------                          -----------                                -----------
0001a2e3-d8e0-496d-a114-a6da4e938a34<EMAIL_ADDRESS><EMAIL_ADDRESS>

Connect-MicrosoftTeams -AccessTokens @("$graphToken", "$teamsToken") -AccountId $ImpersonationUser.id  -Verbose
Connect-MicrosoftTeams : Parameter set cannot be resolved using the specified named parameters.
At line:3 char:1
+ Connect-MicrosoftTeams -AccessTokens @("$graphToken", "$teamsToken")  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Connect-MicrosoftTeams], ParameterBindingException
    + FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.TeamsCmdlets.Powershell.Connect.ConnectMicrosoftTeams

Diagnostic Info:
Get-Module MicrosoftTeams

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     3.1.1      MicrosoftTeams                      {Add-TeamChannelUser, Add-TeamUser, Connect-MicrosoftTeams, Disconnect-MicrosoftTeams...}

I'm not the only person with this issue,
https://techcommunity.microsoft.com/t5/teams-developer/authenticating-with-an-access-token-connect-microsoftteams/m-p/2233794
Someone even blogged about it:
https://get-itips.capazero.net/posts/teams-powershell-token-auth
This issue has also been raised here and been closed with a planned resolution suggested in Sept 2021, but still not available 6x months later...
https://github.com/MicrosoftDocs/office-docs-powershell/issues/8194

Same problem after updating MS Teams PS Module...
Get-Module MicrosoftTeams

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     4.0.0      MicrosoftTeams                      {Add-TeamChannelUser, Add-TeamUser, Connect-MicrosoftTeams, Disconnect-MicrosoftTeams...}

Same problem with the 4.0.1-preview module.

Also having this issue.

There is clearly a large history behind this particular set of commands:

https://github.com/MicrosoftDocs/office-docs-powershell/issues/7866
https://github.com/MicrosoftDocs/office-docs-powershell/issues/7897
https://github.com/MicrosoftDocs/office-docs-powershell/issues/147 (not exactly the same, but closely related)
https://github.com/MicrosoftDocs/office-docs-powershell/issues/8623
https://github.com/MicrosoftDocs/office-docs-powershell/issues/8106
https://github.com/MicrosoftDocs/office-docs-powershell/issues/8136
https://github.com/MicrosoftDocs/office-docs-powershell/issues/8194
https://github.com/MicrosoftDocs/office-docs-powershell/issues/8203
https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/pull/8204
https://github.com/MicrosoftDocs/office-docs-powershell/pull/8788
https://github.com/MicrosoftDocs/office-docs-powershell/pull/8711
https://github.com/MicrosoftDocs/office-docs-powershell/pull/8448

Am struggling to wrap my head around this:
Why are MS Developers closing the github issues down? Especially when the issue is clearly not resolved, and no alternative workaround has been provided?

Using the following command, I retrieved a tiny bit more log data:
Connect-MicrosoftTeams -LogLevel Verbose -LogFilePath %temp%\Connect-MSTeams.log -AccessTokens @($GraphAccessToken,$TeamsAccessToken) -Verbose
Opening the log file:
2022-04-04T14:10:42.0133591Z,Info      ,Logger.Initialize                       ,
Logging initialized at level: Verbose
2022-04-04T14:10:42.0133591Z,Info      ,Logger.Initialize                       ,
Logged in at: 680J1M2-WS
2022-04-04T14:10:42.0133591Z,Info      ,LogAssemblyInfo                         ,
Running assembly 	 assemblyInfo : Microsoft.TeamsCmdlets.PowerShell.Connect, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null 	 assemblyLocation : C:\Program Files\WindowsPowerShell\Modules\MicrosoftTeams\3.0.0\net472\Microsoft.TeamsCmdlets.PowerShell.Connect.dll 	 assemblyName : Microsoft.TeamsCmdlets.PowerShell.Connect, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null	 assemblyVersion : <IP_ADDRESS> 	 fileVersion : <IP_ADDRESS> 	 productVersion : 1.1.5
2022-04-04T14:10:42.0133591Z,Info      ,Connect-MicrosoftTeams.BeginProcessing  ,
Connecting to the AzureCloud environment.
2022-04-04T14:10:42.0602317Z,Info      ,Connect-MicrosoftTeams.ProcessRecord    ,
Connect to MicrosoftTeams with AccessToken.
2022-04-04T14:10:42.0602317Z,Info      ,Connect-MicrosoftTeams.ProcessRecord    ,
Azure account type: AccessToken
2022-04-04T14:10:42.1383334Z,Error     ,Connect-MicrosoftTeams.ProcessRecord    ,
System.NullReferenceException - Object reference not set to an instance of an object..    at Microsoft.TeamsCmdlets.Powershell.Connect.RMProfileClient.GetTokenClaimValue(JsonWebToken webToken, String value)
   at Microsoft.TeamsCmdlets.Powershell.Connect.RMProfileClient.ProcessProvidedAccessTokens(AzureAccount account, String tenantId)
   at Microsoft.TeamsCmdlets.Powershell.Connect.RMProfileClient.AcquireAccessToken(AzureAccount account, AzureEnvironment environment, String tenantId, SecureString password, AuthenticationFlow authFlow)
   at Microsoft.TeamsCmdlets.Powershell.Connect.RMProfileClient.Login(AzureAccount account, AzureEnvironment environment, String tenantId, SecureString password, AuthenticationFlow authFlow)
   at Microsoft.TeamsCmdlets.Powershell.Connect.ConnectMicrosoftTeams.ProcessRecord()
2022-04-04T14:10:42.2478858Z,Info      ,                                        ,
TryConfigApiSessionInfo: Ran into an exception System.UnauthorizedAccessException: Session is not established, run Connect-MicrosoftTeams before requesting access token
   at Microsoft.Teams.ConfigApi.Cmdlets.CmdletHostWrapper.GetAccessToken(String appId)
   at Microsoft.Teams.ConfigApi.Cmdlets.SessionStateStore.Microsoft.Teams.ConfigApi.Cmdlets.ISessionStateStore.GetSessionState()
   at Microsoft.Teams.ConfigApi.Cmdlets.SessionStateStore.get_TryConfigApiSessionInfo()  TryConfigApiSessionInfo C:\a_work\2\s\Microsoft.Teams.ConfigAPI.Cmdlets\generated\custom\SessionStateStore.cs:32
2022-04-04T14:10:42.2478858Z,Info      ,Disconnect-MicrosoftTeams.ProcessRecord ,
User logged out PowerShell session.

There is clearly a large history behind this particular set of commands:
* [Documentation for 2.3.2-preview Connect-MicrosoftTeams with -AccessTokens feature is inadequate #7866](https://github.com/MicrosoftDocs/office-docs-powershell/issues/7866)

* [2.3.2preview Get-Cs commands do not work using AccessTokens login. #7897](https://github.com/MicrosoftDocs/office-docs-powershell/issues/7897)

* [connect-microsoftteams with credential causes error #147](https://github.com/MicrosoftDocs/office-docs-powershell/issues/147) (not exactly the same, but closely related)

* [Errors connecting to teams via AccessTokens #8623](https://github.com/MicrosoftDocs/office-docs-powershell/issues/8623)

* [Unclear API Permissions needed #8106](https://github.com/MicrosoftDocs/office-docs-powershell/issues/8106)

* [AccessTokens paramters for Teams graph API #8136](https://github.com/MicrosoftDocs/office-docs-powershell/issues/8136)

* [Example how to aquire AccessTokens #8194](https://github.com/MicrosoftDocs/office-docs-powershell/issues/8194)

* [Connect-MicrosoftTeams -AccessTokens  not working #8203](https://github.com/MicrosoftDocs/office-docs-powershell/issues/8203)

* [Update teams-powershell-release-notes.md OfficeDocs-SkypeForBusiness#8204](https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/pull/8204)

* [Added PowerShell examples for Connect-MicrosoftTeams with AccessTokens #8788](https://github.com/MicrosoftDocs/office-docs-powershell/pull/8788)

* [Update Connect-MicrosoftTeams.md #8711](https://github.com/MicrosoftDocs/office-docs-powershell/pull/8711)

* [Update Connect-MicrosoftTeams.md #8448](https://github.com/MicrosoftDocs/office-docs-powershell/pull/8448)

Am struggling to wrap my head around this: Why are MS Developers closing the github issues down? Especially when the issue is clearly not resolved, and no alternative workaround has been provided?

Adding #8664.

Hi @sjackson0109 - currently the Access tokens work only with the user context and not with the App context.

Hi @sjackson0109 - currently the Access tokens work only with the user context and not with the App context.

Can you please clarify with an explaination?

Access tokens work only with the user context and not with the App context.

Can you please go into more detail here on how to actually deploy and use access tokens given the above statement, what benefit do they bring?
Please correct me if I am wrong, but as far as I can tell I need to have a user account enabled, configured with Teams RBAC roles, with no MFA configured for any unattended automation in the Teams area.
I think, instead, I should be able to use a service principle here, but if I am understanding the above correctly, this is not possible? I am struggling to understand what the actual supported use case for using access tokens is with this module if that is the case...

Yes, that's correct, the Service Principal support is in works and will be available soon.

Why has this been closed???

@sjackson0109 Here, we are limited to documentation fixes and improvements only. Thanks

Why did Microsoft open the code repo to public to raise issues against; if development support staff just close tickets with no comments or justification? This is shocking behaviour.
As a bare minimum, explain why you can’t progress with the ticket. This is just basic human decency. Put yourself in the shoes of the person raising the ticket; and manage your own expectations as you reply.
Despite having to chase for a justification, I’m still baffled why you decided to close.
This is clearly a bug with the powershell module; not handling the JWT token type APP; when calling the -AccessTokens switch.  It’s a bug that needs fixing, doesn’t that therefore classify the fix as an ‘improvement’ to the code-base?

Hello @sjackson0109 Simon, how are you?
What @yogkumgit is trying to explain, is that github issues under this repository are to handle issues in markdown files (documentation) inside this repository (for example a missing parameter description, a cmdlet that is not documented), not code or module files whatsoever, those kind of issues have different paths to be resolved (like opening a support request from the tenant), please let me know if that is clear.
Anyway, we managed to report this to the product team and they are aware.
Thank you

As several of the linked tickets all suggest, and about 12 pages of another forum; everyone has been raising this with the formal support channels. And nobody is getting any traction.
I personally raised this the exact same day as I started this thread. After several screen sharing sessions; the engineer ultimately gave up stating ‘we are a break fix organisation, so can only support configuration or coding related mistakes on the customer side’.
With no escalation pathway, and this problem stemming back to MicrosoftTeams PS module 2.5.x (we’re now on version 4+)… it MAY have been communicated to the product team in the past; however the evidence stands for itself. This issue is not something they are actually working on.
nobody has any real promise of a fix.

For GitHub developers to look at:
Microsoft’s documentation does not clearly state to ‘use a USER based JWT token (not an App/certificate/secret) to connect to MS Teams with the -AccessTokens switch’.

For GitHub developers to look at:
Microsoft’s documentation does not clearly state to ‘use a USER based JWT token (not an App/certificate/secret) to connect to MS Teams with the -AccessTokens switch’.

Hi Simon @sjackson0109,
I've been following this thread since I have same concerns and have had lengthy discussion of same in the previous issue #8664  I linked. However, the documentation does clearly state that you need to use the "Delegated" context API permission instead of the "Application" context - which ultimately makes the usage of AccessTokens for any Teams administrator managing Teams Voice absolutely useless.
I agree that there doesn't seem to be a proper communication channel either - even the Microsoft Feedback forum has no category for Powershell module and the search is useless. It would be nice if we could all vote for a single feature to raise awareness.

I have added a feedback item to hopefully get a formal commitment to fixing this. Please vote, socialize and share my Teams Powershell feedback item.
https://feedbackportal.microsoft.com/feedback/idea/92b47808-15bd-ec11-a81b-000d3a00c008

@get-itips

I have added a feedback item to hopefully get a formal commitment to fixing this. Please vote, socialize and share my Teams Powershell feedback item.
https://feedbackportal.microsoft.com/feedback/idea/92b47808-15bd-ec11-a81b-000d3a00c008

Also voted. Thanks
@yogkumgit as this is not a documentation issue (on markdown files) we can close it.


Update melonds.json to latest release

Update to latest 0.9 release.

[suggested label:"package update" ]


Cleanup return from void function to avoid confusion

Some static analysis tools (including the ones made out of carbon instead of silicon and bits) read this code and think it may be trying to return a value through a void function:
https://github.com/googleapis/google-cloud-cpp/blob/ddefe5bd3320d99631a886fe4920a09aa7f58053/google/cloud/future_void.h#L75
The tmp->get() expression always returns void, but it is unnecessarily confusing.

"Confusing" may be in the eye of the beholder, but this is C++ where "A return statement with an operand of type void shall be used only in a function whose return type is cv void."  So, I'd say the tool is over reaching.

I thought maybe the tool was being conservative in the face of a template, but the only templates here are fully specialized.  The return type from tmp->get(); is void and can only be void.  On a second look, I agree with @devbww.


Remote Library: Small grammar fixes and rewordings

Thanks! As a non-native English speaker I highly appreciate grammar fixes. I'm going to change the titles to use the Only first word capitalized format, though, because that's what we use also elsewhere in the User Guide.

@pekkaklarck: I'll keep the header format in mind if I do some more reading/editing. Thanks for the good work!


TestLabelsDemoApp failures (flake?)

Hit a TestLabelsDemoApp failure (https://github.com/cilium/tetragon/actions/runs/7472506683/job/20334842561?pr=1948) in https://github.com/cilium/tetragon/pull/1948. Seems like a flake.
Details:
 I0110 09:10:55.961095   14366 dumpinfo.go:240] contacting metrics serveraddrhttp://localhost:2112/metrics
--- FAIL: TestLabelsDemoApp (30.00s)
    --- FAIL: TestLabelsDemoApp/Run_Event_Checks (10.01s)
        --- FAIL: TestLabelsDemoApp/Run_Event_Checks/Run_Event_Checks (10.01s)
            rpcchecker.go:171:
                	Error Trace:	/home/runner/work/tetragon/tetragon/go/src/github.com/cilium/tetragon/tests/e2e/checker/rpcchecker.go:171
                	            				/home/runner/work/tetragon/tetragon/go/src/github.com/cilium/tetragon/vendor/sigs.k8s.io/e2e-framework/pkg/env/env.go:422
                	            				/home/runner/work/tetragon/tetragon/go/src/github.com/cilium/tetragon/vendor/sigs.k8s.io/e2e-framework/pkg/env/env.go:453
                	Error:      	Received unexpected error:
                	            	failed to get events after 10 tries
                	Test:       	TestLabelsDemoApp/Run_Event_Checks/Run_Event_Checks
                	Messages:   	checks should pass
    --- FAIL: TestLabelsDemoApp/Run_Workload (30.00s)
        --- FAIL: TestLabelsDemoApp/Run_Workload/Wait_for_Checker (30.00s)
            rpcchecker.go:107:
                	Error Trace:	/home/runner/work/tetragon/tetragon/go/src/github.com/cilium/tetragon/tests/e2e/checker/rpcchecker.go:107
                	            				/home/runner/work/tetragon/tetragon/go/src/github.com/cilium/tetragon/vendor/sigs.k8s.io/e2e-framework/pkg/env/env.go:422
                	            				/home/runner/work/tetragon/tetragon/go/src/github.com/cilium/tetragon/vendor/sigs.k8s.io/e2e-framework/pkg/env/env.go:453
                	Error:      	failed to wait for checker labelsEventChecker to start after 30s
                	Test:       	TestLabelsDemoApp/Run_Workload/Wait_for_Checker
I0110 09:10:55.961222   14366 dumpinfo.go:299] contacting gops agentaddr<IP_ADDRESS>:8118
FAIL
E0110 09:10:55.961342   14366 dumpinfo.go:303] "failed to dump heap profile" err="failed to dump heap profile: dial tcp <IP_ADDRESS>:8118: connect: connection refused" addr="<IP_ADDRESS>:8118"
coverage: [no statements]
I0110 09:10:55.961425   14366 dumpinfo.go:48] "Dumping test data" dir="/tmp/tetragon.e2e.TestLabelsDemoApp.2402988556"
I0110 09:10:55.961435   14366 dumpinfo.go:233] No checker info to dump
E0110 09:10:55.961716   14366 dumpinfo.go:244] "failed to contact metrics server" err="Get \"http://localhost:2112/metrics\": dial tcp [::1]:2112: connect: connection refused" addr="http://localhost:2112/metrics"
E0110 09:10:56.101977   14366 dumpinfo.go:71] "Failed to extract previous tetragon logs" err="failed to run kubectl logs -c tetragon -n kube-system tetragon-4x65q --previous: exit status 1"
I0110 09:10:56.892134   14366 cluster.go:165] Deleting temporary kind cluster tetragon-ci-5c01
I0110 09:10:56.892181   14366 kind.go:149] Destroying kind cluster tetragon-ci-5c01
I0110 09:10:58.147558   14366 kind.go:159] Removing kubeconfig file /tmp/kind-cluser-tetragon-ci-5c01-kubecfg1496165204
I0110 09:10:58.147660   14366 portforward.go:142] "Test ended, stopping portforward" pod="tetragon-4x65q" namespace="kube-system" ports=["54321:54321","2112:2112","8118:8118"]
FAIL	github.com/cilium/tetragon/tests/e2e/tests/labels	118.314s
ok  	github.com/cilium/tetragon/tests/e2e/tests/policyfilter	127.217s	coverage: [no statements]
ok  	github.com/cilium/tetragon/tests/e2e/tests/skeleton	379.648s	coverage: [no statements]
FAIL
make: *** [Makefile:251: e2e-test] Error 1
Error: Process completed with exit code 2.

More typical timeout example. I think one solution would be to move away from these deployments that are flaky "by nature": they somehow fail to deploy on time even in an environment with enough resources.

Let's make a good first issue to do the migration to the microservices demo. I think it makes a lot of sense.

See https://github.com/cilium/tetragon/issues/1976.

This might be fixed by #2345. Let's keep an eye on this test for a couple of weeks, if it's stable then we can close the issue.

Hi @lambdanis
https://github.com/cilium/tetragon/actions/runs/8966724879/job/24623050943#step:6:9683
time="2024-05-06T09:26:21Z" level=info msg="PROCESS_EXEC:894 => FINAL MATCH "
time="2024-05-06T09:26:21Z" level=info msg="DONE!"
--- FAIL: TestLabelsDemoApp (241.38s)
    --- FAIL: TestLabelsDemoApp/Run_Workload (118.15s)
        --- FAIL: TestLabelsDemoApp/Run_Workload/Run_Workload (118.10s)
            labels_test.go:53: failed to install demo app. run with `-args -v=4` for more context from helm: exit status 1
            labels_test.go:53: failed to install demo app. run with `-args -v=4` for more context from helm: exit status 1
            labels_test.go:53: failed to install demo app. run with `-args -v=4` for more context from helm: exit status 1
            labels_test.go:60: failed to install demo app after 3 tries
FAIL

The test seems successful, but the demo has failed to install. Maybe this is another flake test?
Btw, I'm wondering why we have to install and check labels in parallel instead of installing the demo app successfully and then running the label checker test?
https://github.com/cilium/tetragon/blob/a3b867cb9e77fd1a305c89e4955c0a993e83d8cf/tests/e2e/tests/labels/labels_test.go#L97-L121

Btw, I'm wondering why we have to install and check labels in parallel instead of installing the demo app successfully and then running the label checker test?

I'm not sure indeed. The only reason can be that it can potentially speed up the tests because technically the checker can finish before all the deployments are ready. If it can make debugging easier, maybe we could consider changing that. Do you have any memories on that @willfindlay?


Move mrcnn_mask_target op to contrib

Description

Rename mrcnn_target op to mrcnn_mask_target and move to contrib.
Move the test to test_contrib_operator.py.

Checklist
Essentials

[X] Changes are complete (i.e. I finished coding on this PR)
[X] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[X] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

@zhreshold @Jerryzcn

thanks for the fix!


Allow change in Sync'ing behaviour in already-imported table

Currently it seems like the only way to get a "sync" table is to import it fresh and set the sync frequency then. This means that

users cannot turn a non-synced table into synced at a later date
users cannot change the frequency of a synced table up or down after they've set it up

I noted this with a raster table, but I think it applies to other tables too.

Yep, it applies to all tables in this version.
Will keep on the backlog.
Do you have an use case for the 1st thing you mention? Just out of curiosity

Turning a non-synced table into synced is soft of a "oh, shoot, I meant to make that a synced" kind of thing. You might not be planning ahead as you initially import your data. I can see how it might be more difficult, as the constraints of a synced table (read-only, don't change anything) are hard to apply post-facto.

There has been no activity on this issue for more several months. We are closing it. If you think this still needs to be addressed please open a new issue.


Reset Windows Update Client settings script link broke

Reset Windows Update Client settings script link broke.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 886426b5-8548-1cfc-ccd2-fd03e549c967
Version Independent ID: 599aea76-47e4-dccc-799c-2d8acf549546
Content: Windows Update - Additional resources - Windows Deployment
Content Source: windows/deployment/update/windows-update-resources.md
Product: w10
Technology: windows
GitHub Login: @jaimeo
Microsoft Alias: jaimeo

We are aware of the issue and are working on a replacement.

Duplicate of issues #4930, #9104, #9216, #9281, and #9287 .

Fixed via https://github.com/MicrosoftDocs/windows-itpro-docs/commit/15e9a411fce64546f8572b29691f782b3f4badb1#diff-fc5cd38a44f9cd55d877749fbddbe9dabdf373fbf2348b20aba9581b44062630


Make MACOSX_DEPLOYMENT_TARGET configurable

Also increase the default target to 10.5, since Xcode 10 can no longer
target 10.3.

Coverage increased (+0.1%) to 80.244% when pulling 7c5f9c1a3dd2291db2d3222fa5ed59e9d6b39c3e on jmroot:macosx-deployment-target into 1dfb8c41e8a7e689959baeaf2961437db9615f74 on keplerproject:master.

Coverage increased (+0.1%) to 80.244% when pulling 7c5f9c1a3dd2291db2d3222fa5ed59e9d6b39c3e on jmroot:macosx-deployment-target into 1dfb8c41e8a7e689959baeaf2961437db9615f74 on keplerproject:master.

@jmroot Merged, thank you!


Error while building

<EMAIL_ADDRESS>(6:9): "Redirect" is not exported by "node_modules/react-router-dom/dist/index.js", imported by    │
│<EMAIL_ADDRESS>                                                                                │
│   file: E:/coding/doctorbrain/boss.drbrain/node_modules/strapi-chat-genius/node_modules/@strapi/helper-plugin/dist/index.mjs:6:9

also, useHistory is not available anymore I guess

Okay bro, i will update this project now. Thanks!


HIVE-17812

As noted in the code comments, I laid out the motivation for the breaking changes at https://issues.apache.org/jira/browse/HIVE-17812?focusedCommentId=16204787&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16204787
To re-emphasize, with or without the changes to LIstenerEvent, this will not be backwards compatible for server plugins because of the change from HiveConf to Configuration.  We can explore a shim for this that still lives in the metastore module.
As for backporting to 2, I don't see how that would work.  By not changing the thrift API I believe we'll be able to guarantee that 2 clients work with the standalone server.  And it may be possible to write shims that allow 2 plugins to run against the standalone server.  But actually backporting to the 2 line would be too disruptive.


The full-text query parameter for Fulltext Query String is not valid.

HI,
I have an issue with full-text. The sql script I execute on the server is
select * from dbo.ufn_search('(ISABOUT("mysearch") OR "mysearch")')

My function in the context is
[DbFunction("WordBankContext", "ufn_Search")]
public IQueryable<Search> FullSearch(string search)
{
    if (!string.IsNullOrEmpty(search))
    {
        string[] tmp = search.Split(' ');
        search = "";
        foreach (string s in tmp)
        {
            if (!string.IsNullOrEmpty(search))
                search += " AND ";
            search += $"(ISABOUT(\"{s}\") OR \"{s}\")";
            }
    }

    var searchParameter = search != null ? new ObjectParameter("search", search)
                          : new ObjectParameter("search", typeof(string));
    return ((IObjectContextAdapter)this)
               .ObjectContext.CreateQuery<Search>(string.Format("[{0}].{1}",
                                                  GetType().Name,
                                                  "[ufn_Search](@search)"),
                                                  searchParameter);
}

You did describe what problem you are hitting.

Oh, sorry. I revive an error because he parameter is not valid in the sql function. If I copy 'search' and I use it as in my sql example, it is working. I don't know what it happens in CreateFunction

What is the error. Provide all the details including stack trace.

Error: The full-text query parameter for Fulltext Query String is not valid.

Have you tried tracing what EF is sending to the SqlServer (e.g. using Sql Server Profiler)? This should help figure out what is going on.

Using full-text query in a TVF requires the variable that comes from EF to be the same size as the variable defined in the TVF.
By default it will create a variable NVARCHAR(4000) meaning your TVF will need to have an input variable of NVARCHAR(4000).
exec sp_executesql N'SELECT
    [Extent1].[id] AS [id]
    FROM   [dbo].[Table] AS [Extent1]
    INNER JOIN [dbo].[Search](@Search) AS [Extent2] ON [Extent1].[id] = [Extent2].[Id]',N'@Search nvarchar(4000)',@Search=N'test'

CREATE FUNCTION [dbo].[Search]
(
	@Search NVARCHAR(4000) = '""'
)
RETURNS TABLE AS RETURN
(
	SELECT a.[KEY] AS Id, ISNULL(a.[RANK], 0) AS [Rank]
	FROM FREETEXTTABLE([dbo].[Table], *, @Search, LANGUAGE 0x0) a
)

Full-text query also requires a non blank or a non null value to be passed when called or it will error.

Using full-text query in a TVF requires the variable that comes from EF to be the same size as the variable defined in the TVF.
By default it will create a variable NVARCHAR(4000) meaning your TVF will need to have an input variable of NVARCHAR(4000).
exec sp_executesql N'SELECT
    [Extent1].[id] AS [id]
    FROM   [dbo].[Table] AS [Extent1]
    INNER JOIN [dbo].[Search](@Search) AS [Extent2] ON [Extent1].[id] = [Extent2].[Id]',N'@Search nvarchar(4000)',@Search=N'test'

CREATE FUNCTION [dbo].[Search]
(
	@Search NVARCHAR(4000) = '""'
)
RETURNS TABLE AS RETURN
(
	SELECT a.[KEY] AS Id, ISNULL(a.[RANK], 0) AS [Rank]
	FROM FREETEXTTABLE([dbo].[Table], *, @Search, LANGUAGE 0x0) a
)

Full-text query also requires a non blank or a non null value to be passed when called or it will error.

Worked in my case


Color document header (title bar) and footer (status bar)

This came up at the demo meeting today.

This PR isn't intended to change/address the appearance of the icons. It's just setting the background-colors of the title and status bars.


No 'version' key in the manifest file

Describe the bug （描述一下问题）
A clear and concise description of what the bug is.
Screenshots / Logs / Pcap File（屏幕截图/日志/抓包文件）
If applicable, add screenshots or your home-assistant log file or pcap file to help explain your problem.
请提交相关截图，日志，抓包让开发者能够更快的解决问题
Versions (版本信息)

Home Assistant version: Home Assistant 2021.5.1
Midea msmart version: last

Logger: homeassistant.loader
Source: loader.py:794
First occurred: 16:01:14 (1 occurrences)
Last logged: 16:01:14
No 'version' key in the manifest file for custom integration 'midea_ac'. As of Home Assistant 2021.6, this integration will no longer be loaded. Please report this to the maintainer of 'midea_ac'

As a temporary fix we could add
, "version": "0.1.24"
before the closing curly brace on the last line of manifest.json

updated


Fixing version qualifier of validation-api

Maven is case-insensitive about version qualifiers, but repository proxies may fail to look up this artifact (e.g. Nexus OSS).

Thanks for this pull request -  I wasn't able to automatically merge due to a conflict with another PR, but have added this to the latest code.
Cheers,
Michael


Image width and height not saved

I've it up and it's working fine, but image style is dropped on saving. Any ideas on how to fix that?

Does the editor set any classes, attributes to the IMG tag?

Width and height are written to the style attribute: style="height:677px; width:500px". I just switched the project from using TinyMCE and this problem appeared only on CKEditor. I guess they should go into attributes and Django is deleting all styles, is that so?

It strips styles even with 'allowedContent': True in the CKEDITOR_CONFIGS. Both with and without 'removePlugins': 'stylesheetparser'

https://dev.ckeditor.com/ticket/5547 (patch for 4.4.7 present) > http://docs.ckeditor.com/#!/guide/dev_acf-section-example%3A-disallow-inline-styles-and-use-attributes-instead
'disallowedContent': 'img{width,height}',

doesn't help, it just hides width and height fields completely in the dialogue.

https://github.com/ckeditor/ckeditor-dev/pull/157

Replacing static/ckeditor/ckeditor/plugins/image/dialogs/image.js with https://dev.ckeditor.com/attachment/ticket/5547/image.js doesn't seem to help. Verified that browser loaded the correct one by checking copyright years.

Switching to the image2 plugin helped. Just unpacked image2, widget and lineutils into static/ckeditor/ckeditor/plugins/ directory of an activated app and added
'extraPlugins': 'image2',

to the CKEDITOR_CONFIGS

gallerific and some other addons are getting to old. One of reasons for bigger changes in upcoming releases.


DP-500-Azure-Data-Analyst/Instructions/labs/

Lab title: Query files using a serverless SQL pool
Task: Use SQL to query parquet files
Step:05
Description of issue :
The code is missing wildcard in BULK statement. Hence the query doesn't return what is mentioned in step # 06
SELECT YEAR(OrderDate) AS OrderYear,
COUNT(*) AS OrderedItems
FROM
OPENROWSET(
BULK 'https://datalakexxxxxxx.dfs.core.windows.net/files/sales/parquet/',
FORMAT = 'PARQUET'
) AS [result]
GROUP BY YEAR(OrderDate)
ORDER BY OrderYear
Repro steps:

Thanks @pnk1119 - this has been resolved.


Upgrade to L5.6

Use composer require or update when updating these packages so it writes the correct lock file. Right now the tests will still run using the old packages.

Ahh sorry. I did do that, but forgot to add the lock file to the commit. Just pushed it.

Also use the current branch when making these changes because it has some conflicts with the previous reverted commits.

Done in 4.1.0


ENH: stats: end-to-end array-API support for NHSTs with chi-squared null distribution

Reference issue
Toward gh-20544
Follow-up to gh-20777
What does this implement/fix?
Similar to gh-20777 but for hypothesis tests with a chi-squared null distribution.
Additional information
Technically I should probably be passing symmetric=False in all these calls to _get_pvalue, but alternative='greater' is specified explicitly, so it doesn't really matter.

Oops, yes, all done. Thanks!


refactor: waiting blockchain confirmation loader

Refactor Request
Describe the Refactor Request
We need to refactor our current loader component, which currently displays a pulsing dot, to show a spinner instead. This change aims to improve the visual feedback for users during loading states in our frontend application.

Describe Preferred Solution
Replace the existing pulsing dot loader with a spinning animation. The new spinner should be visually consistent with our application's design language and provide a clear indication of ongoing processes or data loading.

Good job team!


[jest-environment-miniflare] Add Buffer to global

This is to fix an error that came up in my test suite:

ReferenceError: Buffer is not defined
at Object. (node_modules/undici/lib/client.js:409:19)
at Object. (node_modules/undici/index.js:3:16)

I have also ran into this same issue (it's for a library that doesn't check for Buffer in a safe way - which are very common in Node!).


fix(reactivity): ensure that shallow and normal proxies are tracked seperately (close #2843)

This fixes #2843
We currently track reactive proxies in one WeakMap, not differentiating between normal and shallow Proxies. the same is true for readonly proxies.
This means that for each target, only one kind of proxy can be created, because we use these WeakMaps to re-use existing proxies for each known target.
const target = { some: 'value' }
const normalProxy = reactive(target)
const shallowProxy = shallowReactive(target)

expect(normalProxy).not.toBe(shallowProxy)

The above test fails - shallowProxy will in fact be the same proxy as normalProxy.
This PR adds separate WeakMaps to track shallow Proxies on their own, which makes the above test pass.

Ah dang, it seems I had the sort-imports extension active involuntarily.
Let me know wether I should revert those.

Aside: I haven't checked but I am pretty sure readonly works slightly differently?
At least you can wrap a reactive instance into a readonly one and get 2 different objects.
Not sure what happens if you call readonly on the target directly.
Simply the idea of wrapping one object in different reactive wrappers is asking for trouble. That issue should be resolved by "please, don't do this" and maybe make a PR to throw when someone attempts that in debug mode.
The "least" problem in my opinion that this assumes you have the raw target living somewhere + a reactive wrapper alive somewhere else and you attempts to create a 3rd instance that should be a shallow wrapper. That's 3 different instances for the same object, it's recipe for referential identity problem. The best pattern is to only keep only a single reactive proxy alive.
The worst problem is that you have no encapsulation and totally unpredictable code.
But if another part of my code uses the same object through a reactive proxy, then that contract can very easily be broken and that wouldn't be anything but a bug.
If your answer to this is: "no because my code is well organized and will never write back an object that was initially assigned by the shallow proxy"; then organize your code even better and split that object into 2 parts: one clearly deep, the other clearly shallow. Mix and matching based on instances won't lead to nice code.
Just the idea of creating proxies all over the place is wacky to me. Wrap your objects at creation time and your life will be much simpler.
Happy 2021 everyone!

Aside: I haven't checked but I am pretty sure readonly works slightly differently?
At least you can wrap a reactive instance into a readonly one and get 2 different objects.
Not sure what happens if you call readonly on the target directly.

reactive proxies and readonly proxies are tracked in individual WeakMaps, so they don't influence each other. And that makes total sense of course, as you often might want to have a reactive proxy internally, i.e. in a composable function, and expose a readonly proxy publicly in its return value.

Simply the idea of wrapping one object in different reactive wrappers is asking for trouble.

I kind of agree with that sentiment, at least for reactive vs. shallowReactive(*)
The question you raise here is basically wether or not we should allow people to shoot themselves in the foot with these, or force them to find different routes t a solution.
Either way, I'd say the current implementation is to be rated a bug as a shallowReactive should definitely not return a deep reactive proxy without any kind of warning, and vice versa.  Would you agree?

That issue should be resolved by "please, don't do this" and maybe make a PR to throw when someone attempts that in debug mode.

This PR does two things:

It enables us to actually differentiate between shallow and deep reactive proxies by tracking them in their own WeakMaps
It uses these different WeakMaps to allow fo both a deep and shallow reactive proxy to be created for the same target.

Whatever we do, we need 1. (or something like it) to actually be able to differentiate bewteen the two.
For 2., we could:

implement a warning but still return the desired, "correct" proxy
throw an error, essentially forbidding the creation of both a shallow and reactive proxy for the same target

However I'm not sure if we actually want to restrict usage in this way? shallow* proxies are already marked as dangerous/advanced features that can lead to identity hazards and similar problems in the docs, and if people follow the general principle of never touching their raw targets, they wouldn't come into this situation anyway.
So the question becomes: Are there valid use cases where people should be allowed to tread into this dangerous territory, or should we "protect" people from actually going there even if the purposefully want to?

[*]: readonly behaves differently, and I think the change I introduce here to allow both a readonly and shallowReadonly on the same target makes sense and actually fixes a bug.

Either way, I'd say the current implementation is to be rated a bug as a shallowReactive should definitely not return a deep reactive proxy without any kind of warning, and vice versa. Would you agree?

I agree. I would throw in debug mode if someone attempts that.
I'm not one to encourage closed-designs and I'm all for extensible frameworks.
But in this specific instance it just sounds like asking for trouble to me and a good framework should also lead its users away from potential problems.
Are you aware of use-cases where creating one shallow and one deep proxy would look like the good solution?

However I'm not sure if we actually want to restrict usage in this way?

If something appears later on, we can always relax the restriction or come up with a specific design to address the concrete use-case.
On the other hand, tightening would be a breaking change, so it's something that's best decided early on (i.e. now).

Whatever we do, we need 1. (or something like it)

Two "something like it" alternative ideas. Single WeakMap might be more efficient but would require being able to detect whether the proxy is shallow or not:

Could be done by flagging the proxies with a symbol or something;
or with one efficient WeakMap for all + a second "shallow" WeakMaps just to know if the proxy found in the first one is shallow or not. Assuming most proxies are deep, the 2nd would stay pretty empty.

Out of topic:

shallow* proxies are already marked as dangerous/advanced features that can lead to identity hazards and similar problems in the docs

This is an anecdote about my own usage, but I'm using lots and lots of shallow proxies/refs and the more I do so, the more I feel comforted in that choice.
Anyway with all the changes made to Vue since the betas, it's nice that you can use a deep or shallow style by default and both work well without having to fight the framework anymore. To each their own.

Either way, I'd say the current implementation is to be rated a bug as a shallowReactive should definitely not return a deep reactive proxy without any kind of warning, and vice versa. Would you agree?

I agree. I would throw in debug mode if someone attempts that.
I'm not one to encourage closed-designs and I'm all for extensible frameworks.
But in this specific instance it just sounds like asking for trouble to me and a good framework should also lead its users away from potential problems.
Are you aware of use-cases where creating one shallow and one deep proxy would look like the good solution?

However I'm not sure if we actually want to restrict usage in this way?

If something appears later on, we can always relax the restriction or come up with a specific design to address the concrete use-case.
On the other hand, tightening would be a breaking change, so it's something that's best decided early on (i.e. now).

Whatever we do, we need 1. (or something like it)

Two "something like it" alternative ideas. Single WeakMap might be more efficient but would require being able to detect whether the proxy is shallow or not:

Could be done by flagging the proxies with a symbol or something;
or with one efficient WeakMap for all + a second "shallow" WeakMaps just to know if the proxy found in the first one is shallow or not. Assuming most proxies are deep, the 2nd would stay pretty empty.

Out of topic:

shallow* proxies are already marked as dangerous/advanced features that can lead to identity hazards and similar problems in the docs

This is an anecdote about my own usage, but I'm using lots and lots of shallow proxies/refs and the more I do so, the more I feel comforted in that choice.
Anyway with all the changes made to Vue since the betas, it's nice that you can use a deep or shallow style by default and both work well without having to fight the framework anymore. To each their own.

This fixes #2843
We currently track reactive proxies in one WeakMap, not differentiating between normal and shallow Proxies. the same is true for readonly proxies.
This means that for each target, only one kind of proxy can be created, because we use these WeakMaps to re-use existing proxies for each known target.
const target = { some: 'value' }
const normalProxy = reactive(target)
const shallowProxy = shallowReactive(target)

expect(normalProxy).not.toBe(shallowProxy)

The above test fails - shallowProxy will in fact be the same proxy as normalProxy.
This PR adds separate WeakMaps to track shallow Proxies on their own, which makes the above test pass.

i want to connect to you, but fail, because in you pr code, may cause shallowReactive(reactive(shallowReactive(reactive({}))))
infinitelty, may you modify you code?

This fixes #2843
We currently track reactive proxies in one WeakMap, not differentiating between normal and shallow Proxies. the same is true for readonly proxies.
This means that for each target, only one kind of proxy can be created, because we use these WeakMaps to re-use existing proxies for each known target.
const target = { some: 'value' }
const normalProxy = reactive(target)
const shallowProxy = shallowReactive(target)

expect(normalProxy).not.toBe(shallowProxy)

The above test fails - shallowProxy will in fact be the same proxy as normalProxy.
This PR adds separate WeakMaps to track shallow Proxies on their own, which makes the above test pass.

i want to connect to you, but fail, because in you pr code, may cause shallowReactive(reactive(shallowReactive(reactive({}))))
infinitelty, may you modify you code?

@lijingfaatcumt  What behavior would you in that case?

@lijingfaatcumt  What behavior would you in that case?

@lijingfaatcumt What behavior would you in that case?

in vue3, designing reactiveMap and readonlyMap is for cache the proxy version if the target has the proxy or the target is a proxy, but in you pr, the code below will cause the cache useless
let proxy = reactive(origin)
let shallowProxy = shallowProxy(origin)

let proxyCopy = reactive(shallowProxy)
proxyCopy === proxy // false

in code above, i want to make proxyCopy === proxy returns true
in order to solve the problem,the createReactiveObject function may modify follow below
function createReactiveObject(
  target: Target,
  isReadonly: boolean,
  baseHandlers: ProxyHandler<any>,
  collectionHandlers: ProxyHandler<any>,
  proxyMap: WeakMap<Target, any>
) {
  if (!isObject(target)) {
    if (__DEV__) {
      console.warn(`value cannot be made reactive: ${String(target)}`)
    }
    return target
  }
  // target already has corresponding Proxy
  const existingProxy = proxyMap.get(target)
  if (existingProxy) {
    return existingProxy
  }
  if (proxyMap.has(target)) {
    return target
  }
  // target is already a Proxy, return it.
  // exception: calling readonly() on a reactive object
  if (
    target[ReactiveFlags.RAW] &&
    !(isReadonly && target[ReactiveFlags.IS_REACTIVE])
  ) {
    //avoid duplication proxy
    target = toRaw(target)
    const existingProxy = proxyMap.get(target)
    if (existingProxy) {
      return existingProxy
    }
  }
  // only a whitelist of value types can be observed.
  const targetType = getTargetType(target)
  if (targetType === TargetType.INVALID) {
    return target
  }
  const proxy = new Proxy(
    target,
    targetType === TargetType.COLLECTION ? collectionHandlers : baseHandlers
  )
  proxyMap.set(target, proxy)
  return proxy
}

@lijingfaatcumt What behavior would you in that case?

in vue3, designing reactiveMap and readonlyMap is for cache the proxy version if the target has the proxy or the target is a proxy, but in you pr, the code below will cause the cache useless
let proxy = reactive(origin)
let shallowProxy = shallowProxy(origin)

let proxyCopy = reactive(shallowProxy)
proxyCopy === proxy // false

in code above, i want to make proxyCopy === proxy returns true
in order to solve the problem,the createReactiveObject function may modify follow below
function createReactiveObject(
  target: Target,
  isReadonly: boolean,
  baseHandlers: ProxyHandler<any>,
  collectionHandlers: ProxyHandler<any>,
  proxyMap: WeakMap<Target, any>
) {
  if (!isObject(target)) {
    if (__DEV__) {
      console.warn(`value cannot be made reactive: ${String(target)}`)
    }
    return target
  }
  // target already has corresponding Proxy
  const existingProxy = proxyMap.get(target)
  if (existingProxy) {
    return existingProxy
  }
  if (proxyMap.has(target)) {
    return target
  }
  // target is already a Proxy, return it.
  // exception: calling readonly() on a reactive object
  if (
    target[ReactiveFlags.RAW] &&
    !(isReadonly && target[ReactiveFlags.IS_REACTIVE])
  ) {
    //avoid duplication proxy
    target = toRaw(target)
    const existingProxy = proxyMap.get(target)
    if (existingProxy) {
      return existingProxy
    }
  }
  // only a whitelist of value types can be observed.
  const targetType = getTargetType(target)
  if (targetType === TargetType.INVALID) {
    return target
  }
  const proxy = new Proxy(
    target,
    targetType === TargetType.COLLECTION ? collectionHandlers : baseHandlers
  )
  proxyMap.set(target, proxy)
  return proxy
}

Converted this back to a draft as there's both ongoing discussion about the approach itself by @jods4 and an edge case raised by @lijingfaatcumt that isn't covered yet.

Converted this back to a draft as there's both ongoing discussion about the approach itself by @jods4 and an edge case raised by @lijingfaatcumt that isn't covered yet.

Converted this back to a draft as there's both ongoing discussion about the approach itself by @jods4 and an edge case raised by @lijingfaatcumt that isn't covered yet.

@LinusBorg  i have find the new way to solve the problem https://github.com/vuejs/vue-next/pull/3052

Converted this back to a draft as there's both ongoing discussion about the approach itself by @jods4 and an edge case raised by @lijingfaatcumt that isn't covered yet.

@LinusBorg  i have find the new way to solve the problem https://github.com/vuejs/vue-next/pull/3052

Aside: I haven't checked but I am pretty sure readonly works slightly differently?
At least you can wrap a reactive instance into a readonly one and get 2 different objects.
Not sure what happens if you call readonly on the target directly.
Simply the idea of wrapping one object in different reactive wrappers is asking for trouble. That issue should be resolved by "please, don't do this" and maybe make a PR to throw when someone attempts that in debug mode.
The "least" problem in my opinion that this assumes you have the raw target living somewhere + a reactive wrapper alive somewhere else and you attempts to create a 3rd instance that should be a shallow wrapper. That's 3 different instances for the same object, it's recipe for referential identity problem. The best pattern is to only keep only a single reactive proxy alive.
The worst problem is that you have no encapsulation and totally unpredictable code.
But if another part of my code uses the same object through a reactive proxy, then that contract can very easily be broken and that wouldn't be anything but a bug.
If your answer to this is: "no because my code is well organized and will never write back an object that was initially assigned by the shallow proxy"; then organize your code even better and split that object into 2 parts: one clearly deep, the other clearly shallow. Mix and matching based on instances won't lead to nice code.
Just the idea of creating proxies all over the place is wacky to me. Wrap your objects at creation time and your life will be much simpler.
Happy 2021 everyone!

@jods4 i have solve duplication proxy by https://github.com/vuejs/vue-next/pull/3052

Aside: I haven't checked but I am pretty sure readonly works slightly differently?
At least you can wrap a reactive instance into a readonly one and get 2 different objects.
Not sure what happens if you call readonly on the target directly.
Simply the idea of wrapping one object in different reactive wrappers is asking for trouble. That issue should be resolved by "please, don't do this" and maybe make a PR to throw when someone attempts that in debug mode.
The "least" problem in my opinion that this assumes you have the raw target living somewhere + a reactive wrapper alive somewhere else and you attempts to create a 3rd instance that should be a shallow wrapper. That's 3 different instances for the same object, it's recipe for referential identity problem. The best pattern is to only keep only a single reactive proxy alive.
The worst problem is that you have no encapsulation and totally unpredictable code.
But if another part of my code uses the same object through a reactive proxy, then that contract can very easily be broken and that wouldn't be anything but a bug.
If your answer to this is: "no because my code is well organized and will never write back an object that was initially assigned by the shallow proxy"; then organize your code even better and split that object into 2 parts: one clearly deep, the other clearly shallow. Mix and matching based on instances won't lead to nice code.
Just the idea of creating proxies all over the place is wacky to me. Wrap your objects at creation time and your life will be much simpler.
Happy 2021 everyone!

@jods4 i have solve duplication proxy by https://github.com/vuejs/vue-next/pull/3052

@lijingfaatcumt Not having 2 distinct instances for the same object is good, but I still have concerns with the concept of having both a deep and a shallow versions of the same object graph and all the unexpected behaviours it leads to.
It will unwillingly lead to having both raw and reactive versions of instances deeper in the graph.

@lijingfaatcumt Not having 2 distinct instances for the same object is good, but I still have concerns with the concept of having both a deep and a shallow versions of the same object graph and all the unexpected behaviours it leads to.
It will unwillingly lead to having both raw and reactive versions of instances deeper in the graph.

@lijingfaatcumt Not having 2 distinct instances for the same object is good, but I still have concerns with the concept of having both a deep and a shallow versions of the same object graph and all the unexpected behaviours it leads to.
It will unwillingly lead to having both raw and reactive versions of instances deeper in the graph.

@jods4 in reactivity package, we call function reactive ,but may get a shallowReactive version or readonly version, this will make users confused. in my implements, the problems above will be solved. and this will make related reactive function more specific as the function's name show
In addition, I haven’t found the problem you mentioned. adding code of pr in https://github.com/vuejs/vue-next/issues/3007 mentioned, the solution i think is perfect.

@lijingfaatcumt Not having 2 distinct instances for the same object is good, but I still have concerns with the concept of having both a deep and a shallow versions of the same object graph and all the unexpected behaviours it leads to.
It will unwillingly lead to having both raw and reactive versions of instances deeper in the graph.

@jods4 in reactivity package, we call function reactive ,but may get a shallowReactive version or readonly version, this will make users confused. in my implements, the problems above will be solved. and this will make related reactive function more specific as the function's name show
In addition, I haven’t found the problem you mentioned. adding code of pr in https://github.com/vuejs/vue-next/issues/3007 mentioned, the solution i think is perfect.

@lijingfaatcumt reactive returns a readonly version if its input is readonly and that's not something you can remove! I see you've changed the test for that in your PR but it's wrong.
If some code hands you out a readonly object, you should not get around it and start modifying it. If you do so you break the contract and most probably introduce bugs in the code that handed out the readonly object to you.
Take props from Vue itself. It's a readonly reactive object. What good do you think would happen if I start modifying it?
Now the next part is more arguable but to me it's the same thing with shallow and deep. If some part of my code created a shallow reactive object graph, it had a reason. If another part of my code takes the same object graph but then makes it deep, it's likely to have unintended consequences.
And in a nutshell that's why I think this PR is a bad idea.

@lijingfaatcumt reactive returns a readonly version if its input is readonly and that's not something you can remove! I see you've changed the test for that in your PR but it's wrong.
If some code hands you out a readonly object, you should not get around it and start modifying it. If you do so you break the contract and most probably introduce bugs in the code that handed out the readonly object to you.
Take props from Vue itself. It's a readonly reactive object. What good do you think would happen if I start modifying it?
Now the next part is more arguable but to me it's the same thing with shallow and deep. If some part of my code created a shallow reactive object graph, it had a reason. If another part of my code takes the same object graph but then makes it deep, it's likely to have unintended consequences.
And in a nutshell that's why I think this PR is a bad idea.

@lijingfaatcumt reactive returns a readonly version if its input is readonly and that's not something you can remove! I see you've changed the test for that in your PR but it's wrong.
If some code hands you out a readonly object, you should not get around it and start modifying it. If you do so you break the contract and most probably introduce bugs in the code that handed out the readonly object to you.
Take props from Vue itself. It's a readonly reactive object. What good do you think would happen if I start modifying it?
Now the next part is more arguable but to me it's the same thing with shallow and deep. If some part of my code created a shallow reactive object graph, it had a reason. If another part of my code takes the same object graph but then makes it deep, it's likely to have unintended consequences.
And in a nutshell that's why I think this PR is a bad idea.

@jods4 I don't agree with you， the reasons follows belows:
first, readonly proxy, reactive proxy, shallowReactive proxy are different proxy of the origin object, they have different way to operate the origin objects, therefore, there is no problem if we keep them in different places
second, if we call readonly function on the origin object to get readonly proxy named readonlyProxy, then we call reactive function on  readonlyProxy to get reactive Proxy nameed reactiveProxy, readonlyProxy and reactiveProxy are different proxy, if you want to modify the origin object, you can operate reactiveProxy, if you prevent other people from modify the origin object, you should give readonlyProxy to others.
third, as above mentioned, if we give others the readonlyProxy, and others want to have readonly proxy and reactive proxy if others can not access the origin object, how should others do, he has no way to solve the problem. so  rather prevent others from doing something, it is better to let him make his own choices. the question you mentioned disign is that once you has the readonly proxy , you may can not get the reactive proxy, if you can not get the origin object, Obviously, this is not a good design
four, the reactivey package is standalone, it is not only used in vue, but used standalone, or in other package, prevent users from
doing something will break his flexibility and scalability, when we design reactivey package, we should not affect to much by other package in vue, how to use reactive package should consider in other package in vue. and shallow or not is the same reason.

@lijingfaatcumt reactive returns a readonly version if its input is readonly and that's not something you can remove! I see you've changed the test for that in your PR but it's wrong.
If some code hands you out a readonly object, you should not get around it and start modifying it. If you do so you break the contract and most probably introduce bugs in the code that handed out the readonly object to you.
Take props from Vue itself. It's a readonly reactive object. What good do you think would happen if I start modifying it?
Now the next part is more arguable but to me it's the same thing with shallow and deep. If some part of my code created a shallow reactive object graph, it had a reason. If another part of my code takes the same object graph but then makes it deep, it's likely to have unintended consequences.
And in a nutshell that's why I think this PR is a bad idea.

@jods4 I don't agree with you， the reasons follows belows:
first, readonly proxy, reactive proxy, shallowReactive proxy are different proxy of the origin object, they have different way to operate the origin objects, therefore, there is no problem if we keep them in different places
second, if we call readonly function on the origin object to get readonly proxy named readonlyProxy, then we call reactive function on  readonlyProxy to get reactive Proxy nameed reactiveProxy, readonlyProxy and reactiveProxy are different proxy, if you want to modify the origin object, you can operate reactiveProxy, if you prevent other people from modify the origin object, you should give readonlyProxy to others.
third, as above mentioned, if we give others the readonlyProxy, and others want to have readonly proxy and reactive proxy if others can not access the origin object, how should others do, he has no way to solve the problem. so  rather prevent others from doing something, it is better to let him make his own choices. the question you mentioned disign is that once you has the readonly proxy , you may can not get the reactive proxy, if you can not get the origin object, Obviously, this is not a good design
four, the reactivey package is standalone, it is not only used in vue, but used standalone, or in other package, prevent users from
doing something will break his flexibility and scalability, when we design reactivey package, we should not affect to much by other package in vue, how to use reactive package should consider in other package in vue. and shallow or not is the same reason.

@lijingfaatcumt reactive returns a readonly version if its input is readonly and that's not something you can remove! I see you've changed the test for that in your PR but it's wrong.
If some code hands you out a readonly object, you should not get around it and start modifying it. If you do so you break the contract and most probably introduce bugs in the code that handed out the readonly object to you.
Take props from Vue itself. It's a readonly reactive object. What good do you think would happen if I start modifying it?
Now the next part is more arguable but to me it's the same thing with shallow and deep. If some part of my code created a shallow reactive object graph, it had a reason. If another part of my code takes the same object graph but then makes it deep, it's likely to have unintended consequences.
And in a nutshell that's why I think this PR is a bad idea.

@jods4 first, i think readonly, reactive, shallowReactive only give you different types to operate the orgin objec. they are different proxy object. second we can pass arount the readonly by function toRaw and reactive and then operate the origin object, so the problem you said i pass around the readonly is has existing. this is not my fault. third, call reactive function may getting a readonly confused me. i think function's function should obviously to the function's name is important. in addition, reactive package is standalone, it's design should not affected to much by other packages in vue

@lijingfaatcumt reactive returns a readonly version if its input is readonly and that's not something you can remove! I see you've changed the test for that in your PR but it's wrong.
If some code hands you out a readonly object, you should not get around it and start modifying it. If you do so you break the contract and most probably introduce bugs in the code that handed out the readonly object to you.
Take props from Vue itself. It's a readonly reactive object. What good do you think would happen if I start modifying it?
Now the next part is more arguable but to me it's the same thing with shallow and deep. If some part of my code created a shallow reactive object graph, it had a reason. If another part of my code takes the same object graph but then makes it deep, it's likely to have unintended consequences.
And in a nutshell that's why I think this PR is a bad idea.

@jods4 first, i think readonly, reactive, shallowReactive only give you different types to operate the orgin objec. they are different proxy object. second we can pass arount the readonly by function toRaw and reactive and then operate the origin object, so the problem you said i pass around the readonly is has existing. this is not my fault. third, call reactive function may getting a readonly confused me. i think function's function should obviously to the function's name is important. in addition, reactive package is standalone, it's design should not affected to much by other packages in vue

second we can pass arount the readonly by function toRaw and reactive and then operate the origin object, so the problem you said i pass around the readonly is has existing

That's explicitly doing hacky stuff. If you really need / want to, it's fine.
The problem is that reactive is implicitly called on every object that is in a deep reactive object graph.
If a library hands out a readonly object to you, then you put it inside an object graph of your own, at no point should you get back a writable version.
// Let's say gatherStats() is a 3rd-party lib that gives you a read-only view of reactive stats.
let readOnlyStats = gatherStats();

// Let's say this is your component state and you put the stats in it
let myState = reactive({
  name: "Whatever",
  counters: readOnlyStats
});

// Now when you access stats in your model, they're writable?!
// No way this is good.
state.counters.x++;

call reactive function may getting a readonly confused me.

This might be because you misunderstood the contract of the function.
Reactive means that the object will notify when it changes. So you can use it in bindings or watch and they will magically update.
It does say nothing about whether you can write to it or not. readonly is a kind of reactive object.

second we can pass arount the readonly by function toRaw and reactive and then operate the origin object, so the problem you said i pass around the readonly is has existing

That's explicitly doing hacky stuff. If you really need / want to, it's fine.
The problem is that reactive is implicitly called on every object that is in a deep reactive object graph.
If a library hands out a readonly object to you, then you put it inside an object graph of your own, at no point should you get back a writable version.
// Let's say gatherStats() is a 3rd-party lib that gives you a read-only view of reactive stats.
let readOnlyStats = gatherStats();

// Let's say this is your component state and you put the stats in it
let myState = reactive({
  name: "Whatever",
  counters: readOnlyStats
});

// Now when you access stats in your model, they're writable?!
// No way this is good.
state.counters.x++;

call reactive function may getting a readonly confused me.

This might be because you misunderstood the contract of the function.
Reactive means that the object will notify when it changes. So you can use it in bindings or watch and they will magically update.
It does say nothing about whether you can write to it or not. readonly is a kind of reactive object.

second we can pass arount the readonly by function toRaw and reactive and then operate the origin object, so the problem you said i pass around the readonly is has existing

That's explicitly doing hacky stuff. If you really need / want to, it's fine.
The problem is that reactive is implicitly called on every object that is in a deep reactive object graph.
If a library hands out a readonly object to you, then you put it inside an object graph of your own, at no point should you get back a writable version.
// Let's say gatherStats() is a 3rd-party lib that gives you a read-only view of reactive stats.
let readOnlyStats = gatherStats();

// Let's say this is your component state and you put the stats in it
let myState = reactive({
  name: "Whatever",
  counters: readOnlyStats
});

// Now when you access stats in your model, they're writable?!
// No way this is good.
state.counters.x++;

call reactive function may getting a readonly confused me.

This might be because you misunderstood the contract of the function.
Reactive means that the object will notify when it changes. So you can use it in bindings or watch and they will magically update.
It does say nothing about whether you can write to it or not. readonly is a kind of reactive object.

@jods4 i undestand you, and i am wrong

second we can pass arount the readonly by function toRaw and reactive and then operate the origin object, so the problem you said i pass around the readonly is has existing

That's explicitly doing hacky stuff. If you really need / want to, it's fine.
The problem is that reactive is implicitly called on every object that is in a deep reactive object graph.
If a library hands out a readonly object to you, then you put it inside an object graph of your own, at no point should you get back a writable version.
// Let's say gatherStats() is a 3rd-party lib that gives you a read-only view of reactive stats.
let readOnlyStats = gatherStats();

// Let's say this is your component state and you put the stats in it
let myState = reactive({
  name: "Whatever",
  counters: readOnlyStats
});

// Now when you access stats in your model, they're writable?!
// No way this is good.
state.counters.x++;

call reactive function may getting a readonly confused me.

This might be because you misunderstood the contract of the function.
Reactive means that the object will notify when it changes. So you can use it in bindings or watch and they will magically update.
It does say nothing about whether you can write to it or not. readonly is a kind of reactive object.

@jods4 i undestand you, and i am wrong

second we can pass arount the readonly by function toRaw and reactive and then operate the origin object, so the problem you said i pass around the readonly is has existing

That's explicitly doing hacky stuff. If you really need / want to, it's fine.
The problem is that reactive is implicitly called on every object that is in a deep reactive object graph.
If a library hands out a readonly object to you, then you put it inside an object graph of your own, at no point should you get back a writable version.
// Let's say gatherStats() is a 3rd-party lib that gives you a read-only view of reactive stats.
let readOnlyStats = gatherStats();

// Let's say this is your component state and you put the stats in it
let myState = reactive({
  name: "Whatever",
  counters: readOnlyStats
});

// Now when you access stats in your model, they're writable?!
// No way this is good.
state.counters.x++;

call reactive function may getting a readonly confused me.

This might be because you misunderstood the contract of the function.
Reactive means that the object will notify when it changes. So you can use it in bindings or watch and they will magically update.
It does say nothing about whether you can write to it or not. readonly is a kind of reactive object.

@LinusBorg @jods4 i find a new way to solve your problems, and i pull a request to @LinusBorg


Removing geodes from artifacts data

Geodes can not be donated and shouldn't be in the Museum Tracker section

Hey just saw this, sorry it took so long.
Thanks!