feat: Add moveBefore and moveAfter for array-nature collection

feat: Add moveBefore and moveAfter for array-nature collection
Summary:

Add moveBefore and moveAfter API on IndexedCollection
Additional documentations on SignalObserver

Test Plan:

Verify unit tests have passed
Create a collection with nature as Array
Populate the collection with a sequence of items
Call moveBefore or moveAfter API
Verify the .items property reflect the movement

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

Project coverage is 94.64%. Comparing base (6e91bfe) to head (1fe75b2).

Files
Patch %
Lines

src/core/internals/InternalSetList.ts
0.00%
4 Missing :warning:

src/collections/IndexedCollectionBase.ts
50.00%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #31      +/-   ##
==========================================
- Coverage   95.24%   94.64%   -0.61%
==========================================
  Files          18       18
  Lines         421      448      +27
  Branches       68       70       +2
==========================================
+ Hits          401      424      +23
- Misses         12       16       +4
  Partials        8        8

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


[Authenticator] Improve documentation regarding navigation

Before creating a new issue, please confirm:

[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.

Which UI component?
Authenticator
Gradle script dependencies
// Put output below this line
authenticatorVersion = "1.1.0"

Environment information
# Put output below this line
Gradle 8.5

Please include any relevant guides or documentation you're referencing
https://ui.docs.amplify.aws/android/connected-components/authenticator https://ui.docs.amplify.aws/android/connected-components/authenticator/customization#theming https://github.com/aws-amplify/amplify-ui-android/blob/main/samples/authenticator/app/src/main/java/com/amplifyframework/ui/sample/authenticator/MainActivity.kt https://developer.android.com/develop/ui/compose/navigation
Describe the bug
What is the correct way to add Authenticator if you working on a Compose Android App that uses Jetpack Compose Navigation component?
It seems to me that there is conflicting and misleading documentation and code samples in the referred sources. There are basically two approaches that one can take:

Follow the sample code in the Theming documentation
In this case the whole application would be wrapped inside Authenticator and the MainActivity code would look something like this:
MyApplicationTheme {    Authenticator(  signInContent = { signInState -> SignInScreen(signInState) } ) { state ->    	val navController: NavHostController = rememberNavController()     MyAppNavHost(     	authenticatorState = state,            navController = navController            )  } }

Follow the Authenticator sample code in GitHub
In this case we would use the mechanisms available in Compose navigation component and define e.g. AuthenticatorScreen() as a startDestination (= Authenticator.route) in NavHost. AuthenticatorScreen() would look something like this:
`@Composable
fun AuthenticatorScreen(
onShowSignedInContent: () -> Unit
) {
Scaffold { padding ->
Column(
modifier = Modifier
.fillMaxSize()
.padding(padding)
) {
Authenticator(
modifier = Modifier.fillMaxWidth(),
signInContent = { signInState -> SignInScreen(signInState) }
) { state ->
val activity = (LocalContext.current as? Activity)
(activity as MainActivity).signedInState = state
onShowSignedInContent()
}
}
}
}

And passed onShowSignedInContent lambda would do the navigating:
onShowSignedInContent = { navController.navigate(Main.route) }
In this case we have store signedInState somewhere because it can’t be passed as navigation argument.
Also, the screen containing the SignOut -action would receive the following lambda as parameter:
onSignOutClick = {
(activity as MainActivity).signedInState?.signOut()
navController.navigateSingleTopTo(Authenticator.route)
}`
I started experimenting with the 1) but noticed that there is a problem because Authenticator is not placed inside e.g. Scaffold that applies the correct colours from theme and I can’t really do that when using Compose navigation i.e. it’s included in Screen level composables. I then moved to 2) approach which seems to work but are there caveats in the way that you’re aware of? Also, there should be an API  (e.g. Amplify.Auth.fetchCurrentState()) to fetch the current state to avoid need to store it in way shown above code.
So, the question is, which approach is the recommended one?
Reproduction steps (if applicable)
No response
Code Snippet
// Put your code below this line.

Log output
// Put your logs below this line

amplifyconfiguration.json
No response
Additional information and screenshots
No response

Thank you for very fast response.
The issue on option 1 is that it's not enough to just place the Authenticator under application theme and expect the Authenticator to use it.  So, something like this is needed to make it work:
MyApplicationTheme {
Surface(modifier = Modifier.fillMaxSize()) {
Authenticator( signInContent = { signInState -> SignInScreen(signInState) } ) {
state ->  val navController: NavHostController = rememberNavController()
MyAppNavHost( authenticatorState = state, navController = navController )
}
}
}
This is because Surface uses default values (colour, content colour) from theme to apply correct colours. This is just a small detail but maybe you could fix it in Theming chapter I was referring to.
Option 2 might be a bit more appealing because we would be using the standard Jetpack Compose Navigation way of doing things and even use transitions. I however have doubts because I think that Authenticator might not be able to do it's magic if it's only present in the one navigation target? For example, is it able to renew the access token automatically or take user to SignIn if tokens have expired. Maybe I would indeed need to observe AuthenticatorState as shown in your code above and do manual navigation to AuthenticatorScreen when needed.

Thank you for the clarification, I understand better now. Authenticator does not apply a background colour, this is intentional. I'll make a note to tweak the documentation appropriately.
For your second point, the Authenticator composable itself is strictly a UI layer, and does not handle any behavioural logic vis-a-vis the user's session. Token refreshes are handled by the underlying Amplify Auth library, which works whether or not Authenticator is in the composition hierarchy.
Furthermore, as long as AuthenticatorState remains in the hierarchy, it will respond to the user's signed in status - again, independently of whether the Authenticator UI is present or not. This is why you can have Authenticator under a navigation target as long as the AuthenticatorState is hoisted up higher.
Alternatively, you can even instead choose to listen directly to Amplify Auth Events yourself instead of using AuthenticatorState, as this is what that class is doing internally.

Thank you for the advice, I think it's great idea to listen to Auth events directly!
I continued experimenting with the both approaches discussed above but I think they both suffer from same issues. Let's imagine the following user story:

User does signIn and puts the App on background and device on in flight mode.
User brings the App to foreground after the Access token has expired. Amplify is not able to use the Refresh token to renew the Access token so user should be taken to SignIn view immediately but that happens only if App is stopped and restarted.
After App is restarted and SignIn view is shown, the App is put on background again.
Device is set back to normal mode and App is brought to foreground. Amplify should be now able to refresh the Access token and let user in directly as the Refresh token is still valid. However, this happens only when App is stopped and restarted.

Do you agree that my findings indicate that there is a problem and I should file another issue for it?

Hey @pmellaaho. I think in the scenario you described the actual issue is in step 3, you should not be shown the SignIn view if there is still a valid refresh token. The user should still be considered "signed in" in this situation because, once connectivity is restored, they will be able to refresh their access token and continue with their session.
This appears to be a bug in the Amplify Auth library, and there is already an outstanding GitHub issue open for it: https://github.com/aws-amplify/amplify-android/issues/2783. I would recommend following that issue for updates, and I'll ping the team to see if we can make some progress there.

Ok, this is good to know and thanks for letting them know that I'm also interested in getting this resolved!

I've tested scenarios similar to those mentioned by @pmellaaho using AmplifyUIAuthenticator v1.2.2 and AmplifyCore v2.21.0.
Preconditions:

Configured a user pool client with an access and ID token expiry of 5 minutes and a refresh token expiry of 1 hour.

Scenario 1:

Sign in to the app.
Enable Airplane Mode (i.e. disconnecting from Wi-Fi and cellular network).
Force close the app.
Wait for 5 minutes.
Reopen the app.

Observed behavior in scenario 1:

AmplifyUI forces the user to the sign-in screen.

Scenario 2:

Sign in to the app.
Enable Airplane Mode (i.e. disconnecting from Wi-Fi and cellular network).
Wait for 5 minutes.
Call the isSigned function for the session:

 val session = Amplify.Auth.fetchAuthSession() as AWSCognitoAuthSession
 if(session.isSignedIn) {
      val accessToken =  session.accessToken
       ... do something useful..
 }

Observed behavior in scenario 2:

The isSignedIn function returns false.

Questions:

Is the behavior observed in Scenario 1 expected for Amplify UI?
Is the behavior observed in Scenario 2 expected for Amplify Core? I ask because the fix in 2783 suggests that isSignedIn might return true in Scenario 2.
If the behaviors in both Scenario 1 and 2 are expected, should we manually log out the user in Scenario 2, given that the session indicates the user is no longer signed in calling:

Amplify.Auth.signOut()

Hi @JOikarinen. I would say that the scenarios you describe are not expected behaviour. Both of the scenarios are related to the information returned from Amplify, as the logic of whether to show the Sign In screen is driven off the isSignedIn flag from Amplify. I would expect that to have been fixed in Amplify 2.19.1 as per the linked issue https://github.com/aws-amplify/amplify-android/issues/2783.
Just to confirm, when you say you were using "AmplifyCore" 2.21.0, you explicitly added a dependency like the following? The fix was in the Cognito plugin so you'd need this specific dependency.
implementation("com.amplifyframework:aws-auth-cognito:2.21.0")

Thanks @mattcreaser for the quick response. In my experiment I didn't explicitly add the aws-auth-cognito dependency as you suggested. So, I conducted the experiment using the following approach:
 implementation("com.amplifyframework.ui:authenticator:1.2.2") {
        exclude(group = "com.amplifyframework", module = "aws-auth-cognito")
    }
    implementation("com.amplifyframework:aws-auth-cognito:2.21.0")
    implementation("com.amplifyframework:core-kotlin:2.21.0")

With the dependency setup above, Scenario 2 now returns isSignedIn = true, which I believe is the desired behavior. However, Scenario 1 fails at step 5, where Amplify UI displays a "Something went wrong" screen.
I guess that things might start working correctly once a version of ui:authenticator is released with a dependency on aws-auth-cognito:2.21.0. Do you have any estimate on when this release might be available?

Thanks @mattcreaser for the quick response. In my experiment I didn't explicitly add the aws-auth-cognito dependency as you suggested. So, I conducted the experiment using the following approach:
implementation("com.amplifyframework.ui:authenticator:1.2.2") {
        exclude(group = "com.amplifyframework", module = "aws-auth-cognito")
 }
implementation("com.amplifyframework:aws-auth-cognito:2.21.0")
implementation("com.amplifyframework:core-kotlin:2.21.0")

With the dependency setup above, Scenario 2 now returns isSignedIn = true, which I believe is the desired behavior. However, Scenario 1 fails at step 5, where Amplify UI displays a "Something went wrong" screen.
I guess that things might start working correctly once a version of ui:authenticator is released with a dependency on aws-auth-cognito:2.21.0. Do you have any estimate on when this release might be available?

@mattcreaser ui:authenticator:1.2.3 is dependent on aws-auth-cognito:2.18.0. The mentioned scenarios 1 and 2 above are still valid bugs in ui:authenticator:1.2.3. Do you have an estimate of when a fix will be available? Should I file scenarios 1 and 2 as separate bugs for more clarity?

I've retested scenarios mentioned above (i.e. scenario 1 and scenario 2) using AmplifyUIAuthenticator v1.3.0 and AmplifyCore v2.21.1.
I can confirm both scenarios now work as expected.


Refinement on otastatus transition logic

Introduction
This PR introduce refinement over otastatus transition logic.
Motivation
otastatus should relate to the update/rollback operation, not relate to the slots' status.
A SUCCESS status only means the latest update/rollback operation is successful,
meanwhile a FAILURE status only means a failed update/rollback attempt.
Design of refinement
some basic rules are enforced as follow:

only the most recent successfully updated slot has the SUCCESS status, inactive slot always in FAILURE status, except for the case in 2.
UPDATING/ROLLBACKING are only set to standby slot that is receiving an update/rollback.
otaclient will only refer to current booted slot's otastatus file when launching itself.
slot switch will only happen at local update/rollback.

Changes

implement new otastatus transition logic
fix/refinement on rollback implementation, define error types for it
refinement over cboot, grub controller according to 1
refinement on error handling for boot controller

ticket
https://tier4.atlassian.net/browse/T4PB-19077

Rebase old branch and re-commit this PR to supersede #140.

@Bodong-Yang
https://tier4.atlassian.net/browse/T4PB-19284 is fixed by this PR. The fix is needed to test.

@Bodong-Yang https://tier4.atlassian.net/browse/T4PB-19284 is fixed by this PR? The fix is needed to test.

T4PB-19284 is not covered by this PR, as the cause of the issue is different.
T4PB-19284 will be covered by another PR.

T4PB-19284 is not covered by this PR, as the cause of the issue is different.

OK, this issue is required to test for multiple ecu. I'll check if single ecu works or not for this PR.

T4PB-19284 will be covered by another PR.

Good.

[ ] this PR -> prev image
[ ] prev image -> this PR
[ ] this PR -> this PR
[ ] initial -> this PR


feat(preset-mini,preset-wind): add aria-x and data-x support

Addresses #1793 with slight syntax change to align with tailwind

Thank you @chu121su12, I was working on it locally but you made it 🚀


Can not run zoom directly in Linux (via VNC)

Describe the bug
Please help me check issue I can not execute zoom GUI directly in Linux (via VNC)
To Reproduce
Steps to reproduce the behavior: (as attached file)

Desktop (please complete the following information):
I am using Docker Desktop 4.15.0 (93002) is currently the newest version available.

Thanks your support !

Hi @thuongta, do you still have this problem?
I have tested the current Docker image and it works.
Can you try using docker pull kastldratza/zoomrec:latest to load the current image and then test it again?
If that doesn't work either, open a terminal in zoomrec and try to run zoom from the command line.
If that results in an error, feel free to forward it to me.

Hi @thuongta, I think I experienced the same behaviour recently and temporarily fixed it by specifying an older version of Zoom client here:
https://github.com/kastldratza/zoomrec/blob/5ddc5113ccb7263abb72f1b0199f0a2fd51ac80c/Dockerfile#L86
I changed
wget -q -O zoom_amd64.deb https://zoom.us/client/latest/zoom_amd64.deb && \
to
wget -q -O zoom_amd64.deb https://cdn.zoom.us/prod/<IP_ADDRESS>9/zoom_amd64.deb && \
and then rebuild a docker image. Everything started working.
I think the issue might be with the latest Zoom client and as the version of the client is not specified, it keeps working in some images. As I understand it, when you are re-building an image, Docker keeps the Zoom client in cache and as the current URL of https://zoom.us/client/latest/zoom_amd64.deb is not changing with image re-builds it keeps using an older version.


Fix values in mg/dl erroneously multiplied by 18 in profile upload to NS

Currently, a case-sensitive comparison of strings 'mg/dl' and 'mg/dL' causes the profile uploader to multiply the values measured in mg/dl by 18.  So an ISF of 50 mg/dl in OpenAPS becomes an ISF of 900 mg/dl in Nightscout.  And similarly, a target of 90 mg/dl in OpenAPS becomes a target of 1620 mg/dl in Nightscout.   This PR fixes that issue.

@scottleibrand  Not sure if your question is directed to me or not, but I did test it and it works for me.

@scottleibrand I did think of one possible issue that I didn't account for.  If any of these values could be undefined, then they would throw an error when calling toUpperCase() on them.  I can add a check.


chore: only include sentry vite plugin in production bundle

Current dependencies on/for this PR:

main

PR #2707   👈

PR #2708

PR #2709

This comment was auto-generated by Graphite.

@wittjosiah queued this pull request to merge with Graphite.

@wittjosiah merged this pull request with Graphite.


Package-level documentation (#3281)

Not done yet, but contains the initial pass adding to the style guide and changing the stdlib to confirm to the style addition.
Throughout this process I ran into a few "I wish that was better" instances such as those listed in the issue itself. I am in favor of the <PACKAGE>.pony matching in name exactly -- so not added/missing underscores or "s" at the end. However, with the name possibly being confusing (see promise.pony versus promises.pony) I am in favor of making the style to add to some package.pony or other common name rather than copy the package name itself.
Thoughts on the above?
An initial review is fitting, but I expect additional needs to be met before merging. (Some of the package-level documentation I added is meager, but I did not have much to go off of for say strings when stating the purpose of the package.)

As I work on this, is there a way to only run the linter and spellcheck or prevent testing/cross-compilint the stdlib on all platforms?

@rhagenson no. All tests run. There's no way to pick and choose unless you remove them from the configuration files.

Seems an awful waste of CI resources, but the alternative is being able to just turn off failing checks so makes sense. Thank you.

A couple of issues that might be related and could be closed when this is merged: #725 and #616

@ergl I agree that those issues could be rolled into this PR.
For #725, it seems to be done? If the additional work needed is in regards to encoding, then I think #3679 working on rfcs#179 hitting main will require continued work on #725. correct?
For #616, I have not used INI before so whereas I could read the Wikipedia article and take a best shot at improving the docs, I am going into it without prior knowledge.

@Theodus You just majorly flexed on me with those suggested changes. I had no idea that it was possible to have the changes appear with a "commit changes" prompt. I have made similar typo and wording suggestions on the Tutorial. I could have made life so much easier on myself and others if I knew that GitHub had such a feature. Thank you for showing me that was possible.

@rhagenson no problem! I had the same reaction when I first saw this feature used.

If it looks ready to y'all then it probably is ready.
The lasting concern was: Do we want a different style to what/how to name the package level documentation to avoid the situations Andy brought up in the original issue?

@rhagenson what issue brought up by andy?

In #3281 Andy mentioned a couple instances of "is this close enough" and suggested the format I went with, which was using a file named the same as the package itself. By no means a blocking concern, but if we wanted to have a more universal standard such as all package level documentation is in package.pony rather than say files.pony for the files package, I would make those changes (and Style Guide change) before this is merged.

@rhagenson i dont think the close enough is close enough. i think it should match the style guide.

Agreed. My point is then: do we want to change the style guide to avoid instances where it would make sense to have it be "close enough"?
If y'all are okay with this PR as it stands and we do not want to change the style guide further then this PR is ready to merge.

@rhagenson i dont understand what we would change about the style guide. it's very clear as to naming. i think the "close enough" files that andy mentions are style guide violations and should be fixed.

I think part of the confusion here may be that I added the "Package-level Documentation" subsection as part of this PR. According to that addition, the "close enough" instances are violations, but since adding to the style guide is part of this PR we could change if/how/why they are violations.
At think at this point though any conversation around how we want to handle naming the package level documentation file is delaying without benefit.

I think the style guide is good with re to the changes about package level docs that are in this PR @rhagenson

Got it. Then if the decision during sync was all good, this is ready to merge.


avoid boxing in ReactiveProperty.SetValue

This line using object.Equals(object)
https://github.com/neuecc/UniRx/blob/e3cbc24a17c122511c02054a0571ae9e30ad1a6c/Assets/UniRx/Scripts/UnityEngineBridge/ReactiveProperty.cs#L80
It cause boxing if T is ValueType.
Why I avoid EqualityComparer<T>.Default?
The reason is for iOS/AOT, but I dropped AOT support in 5.0.0 so I can use EqualityComparer<T>.
I'll change all boxing equals.

5.1.0 has been released.


Hour drop down shows 24 as a valid entry

Should the hour only display 0 through 23? Also, if the user types an invalid date or time, is there a validation function I can call to check the input?
Thank you for such a great tool!
Everardo

Hi @umbundu ,
Well, 0 through 23 is correct as 24 would then be 0.
24:15 would be an invalid time. The only thing missing here is 24:00, it is 00:00 then.
There is no validation included in tinyDatePicker when the user types something wrong. This task should be of a form validation tool, not of the UI.


How can I schedule tweets natively?

Can we get support for this (Been nearly a year since it was asked about) https://developer.twitter.com/en/docs/twitter-ads-api/creatives/api-reference/scheduled-tweets#post-accounts-account-id-scheduled-tweets
They have it available and I think it would be very helpful to schedule the tweets automatically through python.
Discussed in https://github.com/tweepy/tweepy/discussions/1525

Originally posted by sevenleo February 13, 2021
Can I use Tweepy API to schedule posts?

The Twitter Ads API is for advertisers, not normal user accounts, and there are no plans to support it.
You should look into using the official Twitter supported and maintained Ads API SDK for Python instead.


Create PostgreSQL database if it doesn't exists

📚 Context
Currently, rollups-node expects CARTESI_POSTGRES_ENDPOINT  to provide the right credentials and a database name.
It would be nice if rollups-node could check if the /<database> part of the endpoint could be created in case it doesn't exists and the credentials provided have the right to do it.
✔ Solution
So the logic would be something like this:
if database_exists?
    success
else if can_create_databas?
    create_database
    success
else
    error "No permissions to create database."

In a scenario where a single database is provided for many rollups-node instances, database should be created with unique names to avoid collision.
It could be something like chain-$chainId-dapp-$dappCointractAddres, for ex. chain-11155111-dapp-b3b3efb3ca185b63faf4ed125d7cad3daf4c5dbf

Considering some PostgreSQL cloud providers, with cheaper shared instances, where you only get credentials for a single database, we could provide a flag that would make the node isolate each application inside schemas instead of a database.
This is a common multi-tenant database pattern instead of relying on a database table column to identify the tenants.


Possibility to set null into fk field

Hello. Extremly needed basic feature.

Like a cross in a filter

duplicates #161


Fix scheduling 2 CI jobs for PRs.

Currently, we're scheduling 2 identical build CI jobs for PRs that are from branches inside the Redwood repo as they match both the pull_request and push triggers.
Unfortunately it doesn't look like there's a straightforward way to fix this duplication so I suggest we do the same as OkHttp and only build pull requests and trunk. This means CI won't build branches unless there's an associated PR. Open to suggestions!

So this comes up a lot but I think it's more of a theoretical problem than one in practice. Here's another recent example: https://github.com/cashapp/paparazzi/issues/572
I would prefer not changing it if only because I regularly push branches to test because I don't run many if any tests locally. I don't like the solution of draft PRs because it still sends notifications to watchers.
We have never had a problem with minutes, and the build config isn't duplicated or anything. Additionally, we have this config on nearly every repo so if we change it we should be changing it everywhere. I just don't think we're really causing any problems with it and it supports at least one useful workflow.

Sounds good! If we're not worried about queuing then let's leave it as. The only thing I noticed it because both checks need to pass CI ends up taking the max of the two jobs to finish, which makes CI slightly slower.

Ah I guess because they have the same name and we can only guard it on the name, not the trigger type.
Best we can do is probably parallelize the build to make it faster. Removing the todo sample was an easy win. We can probably remove the counter sample too if we add a web target for emoji search.
There's probably room to do more such as splitting the various test targets.


Support DALL-E 3

DALL-E 3 is now available: https://openai.com/blog/dall-e-3-is-now-available-in-chatgpt-plus-and-enterprise
Need to add 'model' option to CreateImageRequest and set it to "dall-e-3".
In the meanwhile, is there an easy way to add custom fields to a request?

Nevermind, forgot to search PRs: https://github.com/TheoKanning/openai-java/pull/386

I also wish the PR to be approved #386 so that I can use updated version of the dall-e-3 model!

This is fixed in https://github.com/TheoKanning/openai-java/pull/393, I'll deploy a new version soon :+1:

This is included in 0.17.0 🎉


[Review Only] Port autogen_client_side import to appshell_paths.gypi

The translator files give me some problems on Linux.
>> make: *  No rule to make target 'out/Release/obj.target/libcef_dll_wrapper/libcef_dll/ctocpp/test/translator_test_ctocpp.o',
needed by 'out/Release/obj.target/libcef_dll_wrapper.a"'.  Stop.

@nethip @ingorichter @jasonsanjose any idea of why?

I am also getting the same error, and i look for appshell_paths.gypi, and it is much more different than the above, i am building this on opensuse, but when I try to build branch "linux-1547" it builds successfully, bt in this case i want to build the 'master', but it fails with the above error when building,

Not needed anymore. See https://github.com/adobe/brackets-shell/pull/619


Making the Search box to Filter The movies As per the USER

here i have idea that i can make the search box to back to work as the user search in any movie in website the movie will appear as it......
some thing like these
https://user-images.githubusercontent.com/85386116/121799207-63dbe880-cc48-11eb-824b-efd873fed44b.mp4

@theSumeetGithub this issue is already open #6.
Before opening any issue make sure that no other similar issue is open.


Ledger View Event Pub/Sub Protocols

Create structures (protobufs) for event publishing and subscriptions.
Write specifications for publish and subscribe protocols across two networks.
Build/adapt modules to realize this feature for Fabric networks (we will add support for other DLTs in a later milestone).
Augment Fabric testnets and sample apps for event dissemination.
Add tutorial pages to show users how to test this feature.

Cross-network ledger view event subscriptions may occur at any time. View events are published/disseminated across network boundaries ONLY if subscriptions are already registered. But a subscription need be done only once, and this can result in a future stream of events in the opposite direction. The diagram below illustrates a proposal for a subscription protocol.

A proposal for the ensuring event publish protocol is illustrated in the diaram below.

New Weaver components required: NONE
Augmentations to existing Weaver components:

Common protobufs: see later comment
Relays: handle events and event subscriptions
Fabric driver: add listener for Fabric commitment events (either blocks or transactions), manage event subscriptions, package views and proofs in events
Fabric Interoperation chaincode: NONE
Fabric Interoperation Node SDK: OPTIONAL: library functions for event subscriptions and event handling/dispatch
Fabric testnets: NONE
Fabric sample chaincode: NONE
Fabric CLI: commands for event subscription and handlers for received events

The event bus proposal in https://github.com/hyperledger-labs/weaver-dlt-interoperability/blob/main/rfcs/protocols/events/event-bus.md seems like a generalization of our pub/sub protocol, where you can subscribe for a class of events.
When saying this, I am thinking of our pub/sub protocol as for subscribing to updates to a particular key or a variable. If you are viewing the pub/sub protocol as means to subscribe to, more generally, any event or a class of events, then the goals of this seems equivalent to the event bus proposal. Some of the terminologies are different. We could update them and merge that to this proposal.

@dhinakaran2705 Yes, that document was originally created as a "vision" document for event management across networks. As you say, the protocol we have described above is a specific instance of how a generic "event bus" would operate: targeted for subscription and publication of a single event triggered by a single ledger commitment action.
We need to update the event bus RFC and create a separate RFC (linked from the former) for the protocol we are trying to design in this epic. Later, we will try to extrapolate from this protocol and write specs for general subscription and publications occurring through the event bus for classes of events.

Below is a proposal for event subscription structures, used in several steps in the subscription flow, and which need to be recognized by drivers, relays, and application agents (whether built on SDK or CLI).
For cross-network view queries, we made a distinction between the structure used by the application (NetworkQuery) to communicate with the relay and the structure used by relays and drivers for their communications (Query). We will make a similar distinction for the event subscription structure below.
Define NetworkEventSubscription in https://github.com/hyperledger-labs/weaver-dlt-interoperability/blob/main/common/protos/networks/networks.proto as follows:
message NetworkEventSubscription {
  EventType type = 1;
  string transaction_func = 2;
  repeated string policy = 3;
  string address = 4;
  string requesting_relay = 5;
  string requesting_network = 6;
  string certificate = 7;
  string requestor_signature = 8;
  string requesting_org = 9;
  bool confidential = 10;
}

Define EventType and EventSubcription in https://github.com/hyperledger-labs/weaver-dlt-interoperability/blob/main/common/protos/common/events.proto as follows:
enum EventType {
  LedgerState = 0;
  AssetLock = 1;
  AssetClaim = 2;
}

message EventSubscription {
  EventType type = 1;
  string transaction_func = 2;
  repeated string policy = 3;
  string address = 4;
  string requesting_relay = 5;
  string requesting_network = 6;
  string certificate = 7;
  string requestor_signature = 8;
  string request_id = 9;
  string requesting_org = 10;
  bool confidential = 11;
}

Both drivers need to maintain maps of event subscriptions, which will be updated in the subscription flow and looked up in the publication flow. We can define these maps in https://github.com/hyperledger-labs/weaver-dlt-interoperability/blob/main/common/protos/driver/driver.proto as follows:
message DriverEventDb {
  message EventMatcher {
    EventType type = 0;
    string transaction_func = 1;
  }
  map<EventMatcher, EventSubscription> event_subscriptions = 1;
}

The EventType ideally should represent all the events emitted by the source network, so we just need to capture the name of the event that is emitted. To capture the name, string type is needed instead of enum.
DriverEventDb needs a field for Id.

@sanvenDev Regarding the subscription map, I updated the earlier comment. That map needs to be maintained only by the source driver, which needs to create a view request out of an event subscription before attempting to collect proof. (I'll propose another structure for the publishing driver.)
Do we need the source driver to maintain an ID in this map? The map entries are supposed to be long-term, and can trigger several events over the lifetime of the chain.

The destination (subscribing) driver needs to maintain a map of event publications, which will be updated in the subscription flow. We can define this map in https://github.com/hyperledger-labs/weaver-dlt-interoperability/blob/main/common/protos/driver/driver.proto as follows (this includes the structures and field defined in an above comment):
message DriverEventDb {
  message EventMatcher {
    EventType type = 0;
    string transaction_func = 1;
  }
  message ContractTransaction {
    string func = 0;
    repeated bytes args = 2;
  }
  message EventPublication {
    oneof publication_target {
      ContractTransaction ctx = 0;
      string app_url = 1;
    }
  }
  map<EventMatcher, EventSubscription> event_subscriptions = 1;
  map<EventMatcher, EventPublication> event_publications = 2;
}

(Note: the destionation/subscribing driver must maintain both the subscriptions and the publications map whereas the source/publishing driver only needs to maintain the subscriptions map.)

@VRamakrishna, What I feel is that we can have support for specifying the exact event that we want to subscribe for. And this can be achieved by including a string field in the EventSubscription messages.
May be later, we can have an additional event type specific processing, given that we can partition the events emitted by the network into types.

@knarayan Doesn't the transaction_func field serve the purpose you want? And what's wrong with including a placeholder category here? We have an entire category called "ledger views", right? Within a view, we do have names to distinguish one data item of interest from another. I'm following the same logic here.

As far as I can see, we don't need any other data structures. In the publication flow, the publishing driver will generate a regular View and send it to the subscribing driver.

@VRamakrishna What we meant when we said to use string is that, yes source network may potentially emit an unlimited number of events, but adding those events in EventType enum in Weaver source code (protobuf), may be tedious for a dev who is trying to use Weaver as a black box using published packages.  Using string is easy to extend.
That's the only reason, otherwise enum is fine if you think most of the time it may not be required to add more EventTypes by application developer.

@VRamakrishna Now I agree that we don't need extra Id field, since EventSubscription has request_id to uniquely identify this subscription. Do you want to call it request_id? or some name related to event subscription?

@VRamakrishna Also I need to think more on ContractTransaction
Do all the details needed to submit a transaction on subscribing network are there?
If we want to use regular View, we need more information like in fabric: which driver, channel, chaincode where to submit the  transaction on subscribing network.
I think we can use view address and replace index (to indicate which arg needs to be replaced when submitting transaction) instead of ContractTransaction object.

We should probably add a field in EventSubscription to reference the subscribing driver.

 message ContractTransaction {
    string func = 0;
    repeated bytes args = 2;
  }
  message EventPublication {
    oneof publication_target {
      ContractTransaction ctx = 0;
      string app_url = 1;
    }
  }
  map<EventMatcher, EventPublication> event_publications = 2;

This map can be stored at destination relay instead of destination driver, because it is just routing decision which I think relay should make. Also we want only relay-client communication and not driver-client because driver is assumed to be hidden wrt client (that's what I think).

message EventSubscriptionState {
  enum STATUS {
    // pending ACK from remote relay
    PENDING_ACK = 0;
    // Received ACK, waiting for data to be sent from remote relay
    PENDING = 1;
    ERROR = 2;
    COMPLETED = 3;
  };
  string request_id = 1;
  STATUS status = 2;
  string error = 3;
}

protos/common/events.proto:
enum EventType {
  LedgerState = 0;
  AssetLock = 1;
  AssetClaim = 2;
}

message EventMatcher {
  EventType type = 1;
  string transaction_func = 2;
}
message EventSubscription {
  EventMatcher eventMatcher = 1;
  Query query = 2;
}
message EventSubscriptionState {
  enum STATUS {
    // pending ACK from remote relay
    PENDING_ACK = 0;
    // Received ACK, waiting for event subscription confirmation from remote relay
    PENDING = 1;
    ERROR = 2;
    SUCCESS = 3;
  };
  string request_id = 1;
  STATUS status = 2;
  string respMessage = 3;
  EventMatcher eventMatcher = 3;
  EventPublication eventPublicationSpec = 4;
}

message ContractTransaction {
  string driverId = 1;
  string ledgerId = 2;
  string contractId = 3;
  string func = 4;
  repeated bytes args = 5;
  int replaceArgIndex = 6;
}
message EventPublication {
  oneof publication_target {
    ContractTransaction ctx = 1;
    string app_url = 2;
  }
}

protos/networks/events.proto
message NetworkEventSubscription {
  EventMatcher eventMatcher = 1;
  NetworkQuery query = 2;
  EventPublication eventPublicationSpec = 3;
}
service Event {
  // endpoint for a client to subscribe to event via local relay initiating subscription flow.
  rpc SubscribeEvent(NetworkEventSubscription) returns (common.ack.Ack) {}
  // This rpc endpooint is for polling the local relay for subscription state.
  rpc GetSubscriptionState(GetStateMessage) returns(common.events.EventSubscriptionState) {}
}

protos/relay/events.proto
service EventSubscribe {
  // the requesting relay forwards the request from client as EventSubscription to the src-relay
  rpc SubscribeEvent(common.events.EventSubscription) returns (common.ack.Ack) {}
  // Src-relay based upon query (EventSubscription) forwards the same response (Ack)
  // from driver to the dest-relay by calling a new endpoint in dest-relay
  rpc SendSubscriptionState(common.ack.Ack) returns (common.ack.Ack) {}
}

protos/driver/events.proto
service EventSubscribe {
  // the src-relay uses this endpoint to forward the event subsctrption request from dest-relay to driver
  rpc SubscribeEvent(common.events.EventSubscription) returns (common.ack.Ack) {}
}

Updating this data structure:
message EventMatcher {
  EventType type = 1;
  string event_name = 2;
  string transaction_func = 3;
}

This would help in application developer define sets of events, that a client can target to subscribe. (because of event type doesn't seem to be specific enough to me and Krishna)

Comments on message EventMatcher:

I am not sure what the event_name denotes and what it is used for.
We need an additional field to denote the contract or dapp id. In Fabric, this will be the chaincode ID whose transaction we are trying to match.

Updated diagrams:
Event Subscription

Event Publication:

All tasks listed in this epic are complete. The event pub/sub feature can still evolve to offer many more features, but we will open other epics under the Cacti platform for those.


⚠ ClamAV has degraded performance

In 076e003, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 63 ms

Resolved: ClamAV performance has improved in 8c77982.


When we must refresh token?

Hello, Stephan! Thank you for very good demo, it's very useful.
But i've noticed, that you invokes refreshAndGetAuthenticationToken(HttpServletRequest request) method (/refresh-controller) only in tests.
But in real life when this method(controller) must be called? When and how system knows, that its time to refresh token?
I can't find any information about this moment, so decided to ask you.

Hi! Stephan,
how can we refresh an expired token ?

You have to call the endpoint under /refresh with your "old" token and you will receive a new one. Your old has still to be valid at this time.

thanks for your quick answer , but i ve tried to create an angular application that cousumes the authentication api i stored the token in the local storage  every time the client tried to get a resource the intercepter verify if the token is expired and when it expired i tried to get a refreshed token from the expired token

When the token is expired, it is too late to refresh him because he is not accepted anymore. You have to refresh him before he's getting expired.
A small request from me, please use the dot as a punctuation mark, otherwise your posts are difficult to read ;)

i am sorry for my poor english , thanks for your response :)


Update sources from VSO

Update sources from VSO.
npm package version - 0.3.1.

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

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

TTYL, MSBOT;


Is optional parameters formating correct?

Format(Expression [ ,Format [ ,FirstDayOfWeek [ ,FirstWeekOfYear ]]]) in syntax section looks kinda funky.
I would expect: Format(Expression, [Format], [FirstDayOfWeek], [FirstWeekOfYear])

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

ID: 3bb4add8-09d2-3251-6654-aef5bf11fcc4
Version Independent ID: b81975f3-b0c2-52ad-529d-d4ac2c3df9f1
Content: Format function (Visual Basic for Applications)
Content Source: Language/Reference/User-Interface-Help/format-function-visual-basic-for-applications.md
Product: office
GitHub Login: @o365devx
Microsoft Alias: o365devx

@GustavBrock - can you comment on this? I agree that this string is strange; if you agree, I'll fix it.

To be honest, I forgot to debug that - it also looked wrong to me. Thanks for the reminder.
The proposed syntax matches that of IntelliSense:
Format(Expression, [Format], [FirstDayOfWeek], [FirstWeekOfYear])
However, a trailing comma is not allowed - a comma must always be followed by either another comma or a parameter. The extended syntax to reflect this would be close to incomprehensible.

Okay, so should I update the strings to the IntelliSense format that you provided? And just to confirm, there's no space between Format(Expression...?

Yes, that's what I would suggest. And right, no space:

@FlameHorizon @GustavBrock
I changed it to this: Format(Expression, [Format], [FirstDayOfWeek], [FirstWeekOfYear])
Changes should be live by tomorrow. Let me know if you have any questions.


False positive on invoke where src is a machine factory function

Describe the bug
const createInvokeMachine = () => createMachine({ /* ... */ })

const machine = createMachine({
  invoke: {
    // error: [eslint xstate/invoke-usage] The` value of the "src" property in the "invoke" object must be a machine, function, string or an object.
    src: createInvokeMachine()
  },
});

Expected behavior
Machine creation functions should be allowed as an argument to src.
Discussion
I am not sure how powerful ESlint is here - can it actually track that a creation function returns a machine, across imports? It seems like it won't be able to.
Maybe it's fine to allow the rule to accept a function call expression?
Versions (please complete the following information):

Node version: v14.17.3
ESLint version: 7.23.0
eslint-plugin-xstate version: 0.12.2

I am not sure how powerful ESlint is here - can it actually track that a creation function returns a machine, across imports? It seems like it won't be able to.
That's right. Since this is a static code analysis tool (it builds an AST) ESlint does not execute functions to track down the return value.
The best we can do here is to allow functions as a src value. The message actually says functions are allowed so I'm going to check why this fails.

:tada: This issue has been resolved in version 0.13.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

Thanks for the lightning-fast reaction!
Hope you have a great day :)

No problem and thank you for the report!


[#112] Fixed classpath of Atomizer

Added debug output of atomizer cmdline
Removed aggro mode (to be restored when ready)

@rultor  merge

@rultor  merge

@skapral OK, I'll try to merge now. You can check the progress of the merge here

@rultor  merge

@skapral Done! FYI, the full log is here (took me 3min)


Remove automatic addition of node_modules into rails asset load path

Addresses #15
Removes addition of node_modules into Rails asset load path and adds section to the readme to explain when it might be useful and how to enable it

Another 💯 PR!
EXCELLENT!


fix: commented from pipeline_stage import WorkshopPipelineStage

As per https://cdkworkshop.com/30-python/70-advanced-topics/200-pipelines/1000-setting-up.html, keeping below line of code inside 'pipeline_stack.py' fails while doing 'cdk synth' and also 'npx cdk deploy' in then next 2000-create-repo.html page.
from pipeline_stage import WorkshopPipelineStage
Fixes #
Removing this line from above python code in order to succeeds 'cdk synth' and 'npx cdk deploy'
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks the import statement was wrong which is why it would fail. Either should update it as in #560, since we do not make any comment about removing, readding, or even changing it in the next two pages.


NiFi to Marklogic Datahub ingestion process

I am having some problems attempting to ingest data through apache nifi into data-hub. I keep getting errors when attempting to harmonize data in the datahub that is already ingested into a marklogic DB, basically circumventing the "input-flow" process of the datahub framework.
Process I have accomplished :

Excel file into NiFi
NiFi into a MarkLogic DB, i.e staging DB

Process I need assistance with:

I have ingested data into a MarkLogic DB, i.e. staging DB,  I would like to use the datahub to harmonize data from that DB and push that harmonized data into another MarkLogic DB, i.e final DB.

I have been trying to look for some possible resources to help with this process but haven't been successful finding such material.  If someone could point me in the right direction or to an example of such a use case that would solve my issue.
Thanks!

These questions are specific to DHF 4, and thus the new RunFlowMarkLogic processor (for DHF 5 flows) won't be relevant.
For both DHF 4 and DHF 5, it's really necessary to use the FlowRunner Java class in the DHF Java API to run a flow. There's logic in the DHF Java API that is important to running a flow that you will miss out on if trying to run a flow by hitting HTTP endpoints directly in DHF.
You mentioned early on that: "I am attempting to only use NiFi in the raw data ingestion process. I do not want to use NiFi to manipulate any of the data if possible."
That is the right goal with DHF 4 - use PutMarkLogic to ingest data into ML via NiFi, and then follow the DHF 4 docs for running a flow, which will likely involve either using QuickStart or Gradle.

These questions are specific to DHF 4, and thus the new RunFlowMarkLogic processor (for DHF 5 flows) won't be relevant.
For both DHF 4 and DHF 5, it's really necessary to use the FlowRunner Java class in the DHF Java API to run a flow. There's logic in the DHF Java API that is important to running a flow that you will miss out on if trying to run a flow by hitting HTTP endpoints directly in DHF.
You mentioned early on that: "I am attempting to only use NiFi in the raw data ingestion process. I do not want to use NiFi to manipulate any of the data if possible."
That is the right goal with DHF 4 - use PutMarkLogic to ingest data into ML via NiFi, and then follow the DHF 4 docs for running a flow, which will likely involve either using QuickStart or Gradle.


Comments on _update_spot_price_from_web

First, a big thanks for providing this useful functionality.
I'd like to point out 1) a minor bug, 2) a noteworthy observation, and 3) a suggestion for improvement.

First a minor bug. There is a typo in the code. 84600 should be changed to 86400 for daily bars.

An observation. When requesting daily bars (86400  seconds), the timestamp of the returned dataframe is unlike the timestamp for other timeframes.  This may be an end-of-bar timestamp, not a start-of-bar timestamp. For all other timeframes less than a day, the timestamps are the start of the bar. For example, consider this request:
actual trade time = "2022-01-01 12:00:30",  asset = "ETH-USD"

The resulting dataframes returned by HistoricalData() for each of the granularities [60, 300, 900, 3600, 21600, 86400] looks like this.
ETH-USD 60 from: 2022-01-01-12-00 to: 2022-01-01-12-01
                         low     high     open    close    volume
time
2022-01-01 12:00:00  3693.05  3700.00  3693.05  3699.47  9.021474
2022-01-01 12:01:00  3697.54  3699.77  3699.61  3697.95  5.324811

ETH-USD 300 from: 2022-01-01-12-00 to: 2022-01-01-12-05
                         low     high     open    close      volume
time
2022-01-01 12:00:00  3693.05  3700.00  3693.05  3697.45   45.536298
2022-01-01 12:05:00  3696.49  3705.68  3697.44  3705.06  165.421915

ETH-USD 900 from: 2022-01-01-12-00 to: 2022-01-01-12-15
                         low     high     open    close      volume
time
2022-01-01 12:00:00  3693.05  3708.59  3693.05  3708.01  340.493358
2022-01-01 12:15:00  3698.12  3709.37  3708.02  3700.70  275.891478

ETH-USD 3600 from: 2022-01-01-12-00 to: 2022-01-01-13-00
                         low     high     open    close       volume
time
2022-01-01 12:00:00  3693.05  3719.00  3693.05  3716.94  1220.621166
2022-01-01 13:00:00  3706.87  3725.55  3717.10  3710.46  1443.189983

ETH-USD 21600 from: 2022-01-01-12-00 to: 2022-01-01-18-00
                         low     high     open    close        volume
time
2022-01-01 12:00:00  3693.05  3767.00  3693.05  3762.14  16792.730418
2022-01-01 18:00:00  3736.00  3777.82  3761.82  3765.72  22093.874628

ETH-USD 86400 from: 2022-01-01-12-00 to: 2022-01-02-12-00
               low     high     open    close        volume
time
2022-01-02  3718.2  3855.77  3765.98  3828.87  78466.351135

Finally, a suggestion for improvement. As written, the code is returning the highest price during the bar interval, but this may not be representative of the actual price at the time of the transaction. Consider this example (15-minute bars for SHIB on April 5 at 13:45).  If you executed a trade during this bar, your actual fill price could have been anywhere in-between the high and low. The highest price in this example is probably not the most accurate choice. Note that we know the time associated with the open and close prices, but we have no way of knowing when the high and low occurred.

I propose the following algorithm.
Determine the timestamp at the start, end, and half-way point of the quotation bar.
Measure the time distance between the actual trade time and each of the quotation time stamps (start, end, middle).
If the actual trade timestamp is nearest the open timestamp, use the open price.
If the actual trade timestamp is nearest the ending timestamp, use the close price.
If the actual trade timestamp is nearest the middle of the quotation bar, use the average of the open and close prices.
This change should smooth-away spurious price spikes and result in more accurate price lookups.  However, I want to mindful that you picked the high price for a reason.  I'm not sure what that reason was, but maybe you want to keep that behavior.  Perhaps you could introduce a new configuration parameter to allow the user to choose the price lookup behavior.

Thanks for reporting a typo and for the detailed thread: I'm always happy when people get into the guts of the code :-) . I'll fix the typo: the existing code should work even with the different dataframe format, because it accesses only line 0.
Curious: have you actually hit the 1-day case? The code keeps trying larger and larger time windows until it does find some price data. I was hoping Coinbase Pro had historical prices with 1-min precision most of the time and that we almost never needed more than 300 or 900 seconds, so that's why I was asking if you found a case in which the code actually reached the 84600 value.
The reason I picked the highest price is just determinism and ability to explain easily what is happening (e.g. during an audit): I want the code to always pick a value that reflects a simple unchanging principle. Other such principles could be: lowest price, open price, close price, etc. This makes it easy to explain what the code is doing. I would disagree that highest price is not representative: we don't know what the actual price was within the selected time window (whether it's 1-min or 900-min or other), so this means it could be any of the prices within that window and therefore high price is as valid a guess as any other (i.e. low, open, close).
In your algorithm I see a couple of issues (correct me if I'm missing something):

the selected window is the smallest for which there is data (the code tries with 1 min and if there is no data, it retries with 5 mins, etc.), so there is no middle timestamp;
the principle for selecting the price is hard to explain (again, audit).

However I like your idea of being able to pass the "selection principle" as a parameter to the -s switch: perhaps -s could accept an argument like open, close, low, high. Unfortunately I won't have the time to implement it in the near future, but if you'd like to submit a PR for this, I'll be happy to review it!

I'll be happy to work on a PR and contribute something besides bombarding you with questions.
I've never hit the 1-day case, it's something I noticed when I cut and pasted the code into a script to get a better understanding of how it worked.  I'm thinking it will be a good idea to generate a more descriptive log message to document the source of the price lookup.  This will tell us how far the retry mechanism has to go to find a price.
Something to be aware of with the highest price approach is that as the retry mechanism increases the duration of the quotation bar, the open timestamp and the open price stay the same, but the high price strays further and further away from the open price and probably further and further away from the actual trade price.  You can see this in the ETH examples above.  The start time of the quotation bar is never more than one minute away from the actual trade time (assuming the trade time is known precisely).
Thinking about my proposed algorithm a bit more, I think an "interpolated" price could work well -- a weighted average of the open price and the close price, where the weights always add to 1.0.  If the actual trade time is at the start of the quotation bar, the interpolated price will match the open price.  If the actual trade time is at the end of the quotation bar, the interpolated price will match the close price.  As the actual trade time moves farther away from the quotation start time, the relative weight of the open price decreases and the weight of the close price increases proportionally.  Sounds complicated, but it's really very simple.
Are you opposed to adding a section to the config file?  We may add multiple historical quote providers in the future and may need additional configuration parameters to control the price lookup behavior.  For now, I'm envisioning something like this:
[price_lookup]
selection = open
on_bad_quotes = ignore  # or error

I just noticed something else.  Something looks not right in this code.  It looks like the first 3 lines don't have any effect.  The last line always overwrites the notes variable. I can address this in the PR as well.  What is the intended behavior?
    notes: str = ""
    if transaction.notes:
        notes = f"{notes}; "
    notes = f"spot_price read from Coinbase Pro; {transaction.notes if transaction.notes else ''}"

I'll be happy to work on a PR and contribute something besides bombarding you with questions.

Awesome! And keep the questions/comments coming: they're very helpful in improving both code and docs.

I've never hit the 1-day case, it's something I noticed when I cut and pasted the code into a script to get a better understanding of how it worked. I'm thinking it will be a good idea to generate a more descriptive log message to document the source of the price lookup. This will tell us how far the retry mechanism has to go to find a price.

Better logs: sounds good.

Something to be aware of with the highest price approach is that as the retry mechanism increases the duration of the quotation bar, the open timestamp and the open price stay the same, but the high price strays further and further away from the open price and probably further and further away from the actual trade price. You can see this in the ETH examples above. The start time of the quotation bar is never more than one minute away from the actual trade time (assuming the trade time is known precisely).
Thinking about my proposed algorithm a bit more, I think an "interpolated" price could work well -- a weighted average of the open price and the close price, where the weights always add to 1.0. If the actual trade time is at the start of the quotation bar, the interpolated price will match the open price. If the actual trade time is at the end of the quotation bar, the interpolated price will match the close price. As the actual trade time moves farther away from the quotation start time, the relative weight of the open price decreases and the weight of the close price increases proportionally. Sounds complicated, but it's really very simple.

My main concern with an interpolated price is that it's created artificially and doesn't necessarily reflect real price (the interpolated price may not even have occurred in reality). For the same reason I have no problem with high, low, open, close because they are actual numbers returned by the exchange.

Are you opposed to adding a section to the config file? We may add multiple historical quote providers in the future and may need additional configuration parameters to control the price lookup behavior. For now, I'm envisioning something like this:
[price_lookup]
selection = open
on_bad_quotes = ignore  # or error

Not opposed: it's a good idea. Perhaps add the provider as well.

I just noticed something else. Something looks not right in this code. It looks like the first 3 lines don't have any effect. The last line always overwrites the notes variable. I can address this in the PR as well. What is the intended behavior?
    notes: str = ""
    if transaction.notes:
        notes = f"{notes}; "
    notes = f"spot_price read from Coinbase Pro; {transaction.notes if transaction.notes else ''}"

Ouch, nice catch. This is a vestige of an older implementation. You're right that the correct implementation is just line 4: the first 3 lines can be removed.

The historical_price_cache is storing only a single quote, currently the high price, for the AssetAndTimestamp.  To allow the user to select between open, close, high, low, or some kind of average price, we will need to store all 4 prices.  This has some impacts for users with an existing cache. 1) For example, if the user wants to set the spot price to the open price, we cannot use the cached the high price, we need to go back to CoinBase Pro and fetch the prices again. 2) Some users might be upset if we destructively overwrite the existing cache.  Maybe we will need a way to detect a single-price cache and non-destructively upgrade to a multi-price cache when loading and saving the cache. Not sure what is the best approach here.  @jamesbaber1 has a different caching approach mentioned in https://github.com/eprbell/dali-rp2/issues/7#issuecomment-1073134971.

The existing DaLI cache is fairly simple and doesn't even have the ability to check for new values in the native source. As it is it's meant to be used by developers as a way to speedup runtime. It's not that useful to users, at least until we implement the ability to update the cache with new values.
I would suggest a simple approach like this:

read element from cache;
if the element is not a 4-value list, then ignore it and overwrite the cache with the 4-value list.

With this approach the worst that can happen is that one run will be slower than the user expects.

Currently how I have implemented my cache is in several levels. price history, raw trades, and then normalized trades. Which has help with debugging and also minimizing web requests when re-running.
The price history cache works like this:

Fetch the 1m ohlcv data for a pair according to the delta of time around the trade which in my case I set to the day, so all minutes from the day.
Currently using Panada's nearest method to match the trade time stamp with the closest minute that was available. (Some days are missing minutes for periods of time so sometimes a few minutes off is a good as you can do)
Save the data frame to a csv
next time price history is requested that csv is loaded first nearst value is scanned and if it is a minute off it requests data from the exchange and concatenates them, drops duplicates and reindexes the data frame then saves it again.

I'll have to run some speed tests,but there is alot of optimization that I could still do. At the moment just trying to ensure I'm using the most accurate data available.
Also was thinking about this too, cause so far have been using the close, but was going to circle back to this. Obviously your trade took place inside some candle stick resolution, and letting the user have a few options would be nice. Like say if the user want to always over report it chooses the highest value out of ohcl on a buy and the lowest value on the sell. Or more of an average etc like @stevendavis mentioned.

The way to fix that is to add a .pyi file in the src/stubs directory, which contains a few examples of pyi stubs for other libraries that don't have typing information. The .pyi file contains typed "declarations" for the symbols you're using (no need to add declarations for everything in the library, just what you need).

Ah good to know. I have never attempted to package pandas a dependency before.  Yea if you haven't used pandas before, it has some great use cases, especially when it comes to working with tables. Don't know if I could make a faster sorting and searching algorithm with just python lists for this use case, but I know pandas is pretty optimized and most of the compute is done in the binary and not python, so I figured it would be pretty fast, but would need to do some speed tests against a python only implementation to verify tho.

@eprbell Thanks for the tip. It was a struggle, but I was eventually able to stop the MyPy errors.
I've run into a snag with the unit tests.  I modified the code to force UTC timezone, and now the TestODSOutputDiff unit tests are failing.  I may be mistaken, but I think the unit test expected results are incorrect and will need to be updated. What do you think?
        transaction_utc_timestamp = transaction.timestamp_value.astimezone(timezone.utc)  # CB Pro API expects UTC only
        from_timestamp: str = transaction_utc_timestamp.strftime("%Y-%m-%d-%H-%M")
        retry_count: int = 0
        while retry_count < len(time_granularity):
            try:
                seconds = time_granularity[retry_count]
                to_timestamp: str = (transaction_utc_timestamp  + timedelta(seconds=seconds)).strftime("%Y-%m-%d-%H-%M")

I'm not sure: can you post the code so I can see it?

Closing after recent PRs.
https://github.com/eprbell/dali-rp2/pull/31
https://github.com/eprbell/dali-rp2/pull/36
https://github.com/eprbell/dali-rp2/pull/44


Texture fixes

The BC7 had issues with alpha.
Before:

After:

The BC6H looked wrong on especially bright spots, such as the sun.
Also cubemap textures (skybox and envmaps) had incorrect offset for mips.
Before:

After:

Thank you!


o365: Error on device update!

Since version 3.1.0 I get following error after restarting Home Assistant (2022.5):
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 431, in _async_add_entity
    await entity.async_device_update(warning=False)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 736, in async_device_update
    await task
  File "/config/custom_components/o365/calendar.py", line 209, in async_update
    start = O365CalendarData.to_datetime(event.start)
  File "/config/custom_components/o365/calendar.py", line 395, in to_datetime
    elif "date" in obj:
TypeError: argument of type 'datetime.date' is not iterable

Ok. I’ll take a look over the next couple of days. Try downgrading to previous version which will still work on HA 2022.5

I'm working on a fix, this impacts all day events


Styling should support inheritance

In order to support a consistent theme within an application, style setters must be duplicated for each control template. It would be nice to have something like Tailwind CSS where classes are used to define properties. For example, the following doesn't work, despite TextBlock inheriting from Control:
<Window.Styles>
    <Style Selector="Control.h-center">
        <Setter Property="HorizontalAlignment" Value="Center" />
    </Style>
</Window.Styles>

<TextBlock Text="{Binding Greeting}" Classes="h-center" VerticalAlignment="Center" />

Describe the solution you'd like
I would like my selector to be Layoutable.h-center.
Additional context
Centering horizontally is a contrived example, but this idea is easily usable to enforce, say, a consistent background color on certain controls, through generic styles instead of duplicated <Setter Property="SomeProperty" Value="{DynamicResource SomethingSomething}" /> on each control's stylesheet.

Selector=":is(Layoutable).h-center" works! Thanks!


minor fixup on JavaDoc for splitters

Running the javadoc Gradle task for the marklogic-client-api/build.gradle file (either from the command line or
by right clicking in the IDE) reports a few warnings about missing param or  desc tags from the splitter classes.
It's a low priority, but when there's a gap between other commitments, that would be good to clean up.  Thanks!

getCoung() method needs a description in Java docs.

Fixed. Verified code and pages after running Javadocs tasks.

There's no server-side change in this issue.


Add 108 in c language

File(s) Modified: 108-convert-sorted-array.c
Language(s) Used: c
Submission URL: _https://leetcode.com/submissions/detail/832078595/_

Thanks, @julienChemillier!


Directory Chooser - contents and themes  ?

Hi,
Just started playing with this code,
When you use the directory chooser i don't seem to be able to show the contents of the folder prior to pressing the select button so once you have navigated to the selected folder the contents are empty?
Also whats the implication of using themes ?.

Hey there,
If you are trying to access a directory that cannot be accessed without root access, the contents will be empty, that is why there is a default dir button to navigate to the specific default directory i case of a user reached that directory.
as for the theme part the dialog follows app theme if no theme id is given, if an id is given the dialog will be themed accordingly, however the icon color and text color cannot be changed, to change that you need to extend the given style in the library and define your values


Use UTF-8 without BOM for SyntaxPrinter

Closes #4912
TODOs:

There are still some failing tests

@tobias-tengler do not worry about the tests, we are on it .... we should be green again by next week.

Resolved all of the test failures that were caused by this change. So this should be good to go! :)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I think this would still be valuable.


boss_db_pmod_pt not handle map

The code: NewAccount = Account#{password_hash => NewHash},
The error:
ERROR: pre_compile failed while processing /home/dcy/yxq: {'EXIT',
{function_clause,
[{boss_db_pmod_pt,expr,
[{map,200,
{var,200,'Account'},
[{map_field_assoc,200,
{atom,200,password_hash},
{var,200,'NewHash'}}]},
{pmod,
['Req'],
{28,
{{my_blacklist,2},
{{change_name,2},
{{already_games,2},
{{activate,2},
{{'_routes',0},nil,nil},
{{add_blacklist,2},nil,nil}},
{{cancel_blacklist,2},
{{avatar,2},nil,nil},
{{cancel_follow,2},nil,nil}}},
{{followings,2},
{{follow,2},
{{change_password,2},nil,nil},
{{followers,2},nil,nil}},
{{logout,2},{{login,2},nil,nil},nil}}},
{{register,2},
{{people,2},
{{my_followings,2},
{{my_followers,2},nil,nil},
{{participate_games,2},nil,nil}},
{{profile,2},{{personal_homepage,2},nil,nil},nil}},
{{update_description,2},
{{reset_password,2},
{{req_reset_password,2},nil,nil},
{{timelines,2},nil,nil}},
{{want_games,2},
{{update_signature,2},nil,nil},
nil}}}}}}],
[{file,"src/boss_db_pmod_pt.erl"},{line,296}]},
Not every code like this will throw error, the code in other location will not throw error.

@dcy, thanks for a patch, closing


remove redundant initializers from constructors

Since D default initializes things.

Yes!  There are a bajillion of these that I'll be happy to see go.


Add Gaussian system library format output

The current Gaussian'94 format causes Gaussian to crash if the basis set has elements that are not included in the calculation.
This PR adds a new output format that adds the - sign in front of the element symbols, so that Gaussian runs smoothly even if you don't have some elements present.

@bennybp ready to merge


Initial commit. Added support for register confirmation and personal …

Initial support for Register Confirmation and Personal Data download/delete.

Ok thanks. Not sure how that got in there. Will take a look.
Mark Nash
Senior Software Engineer        [cid:PC_42x23_fbb4e57e-65d2-4c41-b09e-ffa9f4a3c468.png]
PartnerComm, Inc.
Winner of 86 IABC Gold Quills
2022 Large Agency of the Year
2304 W Interstate 20, Suite 250
Arlington, TX 76017
[cid:pcomm25+_471933a4-f842-490b-84d4-910cf0397a29.png]
Office:<PHONE_NUMBER>
@.***
www.partnercomm.nethttp://www.partnercomm.net
This e-mail transmission may contain confidential information or may be otherwise legally privileged. If you are not the intended recipient you are hereby notified that any use, disclosure, copying, forwarding, or distribution of any of the information contained in or attached to this message is STRICTLY PROHIBITED.

From: Damian Edwards @.>
Sent: Wednesday, July 13, 2022 6:11 PM
To: DamianEdwards/BlazorIdentity @.>
Cc: Mark Nash @.>; Author @.>
Subject: Re: [DamianEdwards/BlazorIdentity] Initial commit. Added support for register confirmation and personal … (PR #2)
[EXTERNAL SENDER]
@DamianEdwards requested changes on this pull request.

In src/BlazorIdentity/BlazorIdentity.csprojhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDamianEdwards%2FBlazorIdentity%2Fpull%2F2%23discussion_r920581211&data=05|01|mnash%40partnercomm.net|9cfd534d634d49f8988008da6524ffe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637933506845684635|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=WiMBj%2FdJl8i%2F0OsRMqIffeHo0737MlWM%2Bsi7Q0%2BaOis%3D&reserved=0:

@@ -6,4 +6,8 @@

 <Nullable>enable</Nullable>

You can't reference that package in this project. The point of the BlazorIdentity project is to be usable in all Blazor projects and that package is only for use in ASP.NET Core projects, and even then, only in unsupported versions, as that package was deprecated a long time ago. You need to add types in this project that shim/wrap the actual Identity types, in this case I think that's UserLoginInfo.
—
Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDamianEdwards%2FBlazorIdentity%2Fpull%2F2%23pullrequestreview-1038071713&data=05|01|mnash%40partnercomm.net|9cfd534d634d49f8988008da6524ffe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637933506845684635|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=BoG2D%2FsmTwKUrIVnBEJF1b502aAYn5L4oK2NZn6429U%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKOLVX4B4OA56ASASRKUA43VT5EJRANCNFSM53JLCB2Q&data=05|01|mnash%40partnercomm.net|9cfd534d634d49f8988008da6524ffe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637933506845684635|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=ebIK3%2FGPijwZQ7HlKb0FeVmvV4TXt6UyUTaQM7ZOyeo%3D&reserved=0.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

Ugh. I removed it from the project instead of deleting. Inadvertently added in the wrong place while solving for that UserLoginInfo dependency issue.
Fixed and pushed.
Mark Nash
Senior Software Engineer        [cid:PC_42x23_fbb4e57e-65d2-4c41-b09e-ffa9f4a3c468.png]
PartnerComm, Inc.
Winner of 86 IABC Gold Quills
2022 Large Agency of the Year
2304 W Interstate 20, Suite 250
Arlington, TX 76017
[cid:pcomm25+_471933a4-f842-490b-84d4-910cf0397a29.png]
Office:<PHONE_NUMBER>
@.***
www.partnercomm.nethttp://www.partnercomm.net
This e-mail transmission may contain confidential information or may be otherwise legally privileged. If you are not the intended recipient you are hereby notified that any use, disclosure, copying, forwarding, or distribution of any of the information contained in or attached to this message is STRICTLY PROHIBITED.

From: Damian Edwards @.>
Sent: Friday, July 15, 2022 12:33 PM
To: DamianEdwards/BlazorIdentity @.>
Cc: Mark Nash @.>; Author @.>
Subject: Re: [DamianEdwards/BlazorIdentity] Initial commit. Added support for register confirmation and personal … (PR #2)
[EXTERNAL SENDER]
@DamianEdwards requested changes on this pull request.

In samples/BlazorIdentity.ServerApp/BlazorIdentity.ServerApp.csprojhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDamianEdwards%2FBlazorIdentity%2Fpull%2F2%23discussion_r922381058&data=05|01|mnash%40partnercomm.net|e86f0170547b4ddc02aa08da66881fe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637935032102899762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=IU4zln5Xh%2F%2BtpFMKVdMA7aWtHgUbba5nqnCKWwHvaxU%3D&reserved=0:

@@ -6,6 +6,10 @@

 <ImplicitUsings>enable</ImplicitUsings>

This is strange, is this meant to be here?

In src/BlazorIdentity.Server/Properties/launchSettings.jsonhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDamianEdwards%2FBlazorIdentity%2Fpull%2F2%23discussion_r922382783&data=05|01|mnash%40partnercomm.net|e86f0170547b4ddc02aa08da66881fe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637935032102899762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=zYKRJ0nffyBA9N%2BVuByLS5vVgdBOcClMtVRbtOAewHM%3D&reserved=0:

@@ -0,0 +1,12 @@

+{

"profiles": {

This shouldn't have a launchSettings.json file as it's just a library.

In src/BlazorIdentity/Properties/launchSettings.jsonhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDamianEdwards%2FBlazorIdentity%2Fpull%2F2%23discussion_r922383118&data=05|01|mnash%40partnercomm.net|e86f0170547b4ddc02aa08da66881fe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637935032102899762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=3w9qGxl%2Bo1uCysLjWH3sCdv96%2BYgZFI25%2By7xYNejjo%3D&reserved=0:

@@ -0,0 +1,12 @@

+{
Same as above, this shouldn't be here.

In src/BlazorIdentity/UserLoginInfoResult.cshttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDamianEdwards%2FBlazorIdentity%2Fpull%2F2%23discussion_r922383680&data=05|01|mnash%40partnercomm.net|e86f0170547b4ddc02aa08da66881fe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637935032102899762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=RS8lcOR84O4JYNEkGAoMSiKfs7tznL76h6Z8uKpMUok%3D&reserved=0:

@@ -0,0 +1,13 @@

+namespace BlazorIdentity;
+using System;
+using System.Collections.Generic;
+using System.Linq;
+using System.Text;
+using System.Threading.Tasks;

+public class UserLoginInfoResult
Let's just keep it the same name as the type it's shimming, like the other shim types in this library.
—
Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDamianEdwards%2FBlazorIdentity%2Fpull%2F2%23pullrequestreview-1040608042&data=05|01|mnash%40partnercomm.net|e86f0170547b4ddc02aa08da66881fe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637935032102899762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=LJOEG9aLzQIbQuFaMEwLMH65SITJpH%2F8xqnjOKd%2FefQ%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKOLVXZQ2OD64OTZJCESVW3VUGOGLANCNFSM53JLCB2Q&data=05|01|mnash%40partnercomm.net|e86f0170547b4ddc02aa08da66881fe2|f2b31dc21677463d8cf12150d7ff1100|0|0|637935032102899762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=4sf6n8skeGdlmfZTSXUOHqh6fDL6tDHv9dBTNFxob4k%3D&reserved=0.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

Hi
Just an FYI. I have started going thru the source code and documenting redirects in the UI project code, which components are called in the src/BlazorIdentity.UI project and callbacks in that project.
Once I have it documented I will fix any glaring inconsistencies. It hopefully should help with determining how redirects etc should be handled.
I should be able to finish the document off tomorrow some time.
Cheers
Mark
Mark Nash
Senior Software Engineer        [cid:PC_42x23_fbb4e57e-65d2-4c41-b09e-ffa9f4a3c468.png]
PartnerComm, Inc.
Winner of 86 IABC Gold Quills
2022 Large Agency of the Year
2304 W Interstate 20, Suite 250
Arlington, TX 76017
[cid:pcomm25+_471933a4-f842-490b-84d4-910cf0397a29.png]
Office:<PHONE_NUMBER>
@.***
www.partnercomm.nethttp://www.partnercomm.net
This e-mail transmission may contain confidential information or may be otherwise legally privileged. If you are not the intended recipient you are hereby notified that any use, disclosure, copying, forwarding, or distribution of any of the information contained in or attached to this message is STRICTLY PROHIBITED.

Good afternoon,
Sorry to bother you, but this issue is really starting to wear me out.
Quick question for you. The answer is probably quite simple. This may be due to my lack of knowledge on the deep plumbing of Identity etc. and probably OOP theory too.
I am fiddling around with implementing External Login. I have the call to Google and the subsequent callback firing correctly but having an issue at that point.
I am implementing the POST to external login with an API controller. Once I get the callback I attempt to do the following:
    var info = await _signInManager.GetExternalLoginInfoAsync();
    if (info == null)
    {
        ErrorMessage = $"Error loading external login information.";
        RedirectToPage("/account/login");
    }
    var userName = info!.Principal.Claims.Where(x => x.Type == ClaimTypes.Email).First().Value;
    var user = await _userManager.FindByEmailAsync(userName);

The call to FindByEmailAsync fails every time with an error saying it cannot find the SQL connection. This is not a problem with regular logins. Just external logins in this API controller. The constructor is like this:
public class AccountController : ControllerBase
{
private readonly IBlazorSignInManager _signInManager;
private readonly IBlazorUserManager<AppUser> _userManager;
public string ErrorMessage { get; set; } = string.Empty;

public AccountController(IBlazorSignInManager<AppUser> signInManager, IBlazorUserManager<AppUser> userManager)
{
    _signInManager = signInManager;
    _userManager = userManager;
}

}
Any ideas or thoughts on where I should look?
Cheers,
Mark
Mark Nash
Senior Software Engineer        [cid:PC_42x23_fbb4e57e-65d2-4c41-b09e-ffa9f4a3c468.png]
PartnerComm, Inc.
Winner of 86 IABC Gold Quills
2022 Large Agency of the Year
2304 W Interstate 20, Suite 250
Arlington, TX 76017
[cid:pcomm25+_471933a4-f842-490b-84d4-910cf0397a29.png]
Office:<PHONE_NUMBER>
@.***
www.partnercomm.nethttp://www.partnercomm.net
This e-mail transmission may contain confidential information or may be otherwise legally privileged. If you are not the intended recipient you are hereby notified that any use, disclosure, copying, forwarding, or distribution of any of the information contained in or attached to this message is STRICTLY PROHIBITED.

Good evening,
Go ahead and completely discard my previous email (shown below) about a weird issue with GetExternalLoginInfoAsync. I finally had some time to dig a little further and found that the code was looking at the OnConfigured property of the DBContext, which led me to the cause.  I had been fiddling with the new bits for SQL 2022 so changed the appsettings.json to point to a copy of the identity DB running that SQL instance inside a VM.  I neglected to change the settings back after discarding the VM. Hence, the timeouts.
Have a good weekend,
Mark
Mark Nash
Senior Software Engineer        [cid:PC_42x23_fbb4e57e-65d2-4c41-b09e-ffa9f4a3c468.png]
PartnerComm, Inc.
Winner of 86 IABC Gold Quills
2022 Large Agency of the Year
2304 W Interstate 20, Suite 250
Arlington, TX 76017
[cid:pcomm25+_471933a4-f842-490b-84d4-910cf0397a29.png]
Office:<PHONE_NUMBER>
@.***
www.partnercomm.nethttp://www.partnercomm.net
This e-mail transmission may contain confidential information or may be otherwise legally privileged. If you are not the intended recipient you are hereby notified that any use, disclosure, copying, forwarding, or distribution of any of the information contained in or attached to this message is STRICTLY PROHIBITED.

From: Mark Nash @.>
Sent: Monday, August 8, 2022 1:31 PM
To: DamianEdwards/BlazorIdentity @.>
Subject: Quick Question
Good afternoon,
Sorry to bother you, but this issue is really starting to wear me out.
Quick question for you. The answer is probably quite simple. This may be due to my lack of knowledge on the deep plumbing of Identity etc. and probably OOP theory too.
I am fiddling around with implementing External Login. I have the call to Google and the subsequent callback firing correctly but having an issue at that point.
I am implementing the POST to external login with an API controller. Once I get the callback I attempt to do the following:
    var info = await _signInManager.GetExternalLoginInfoAsync();
    if (info == null)
    {
        ErrorMessage = $"Error loading external login information.";
        RedirectToPage("/account/login");
    }
    var userName = info!.Principal.Claims.Where(x => x.Type == ClaimTypes.Email).First().Value;
    var user = await _userManager.FindByEmailAsync(userName);

The call to FindByEmailAsync fails every time with an error saying it cannot find the SQL connection. This is not a problem with regular logins. Just external logins in this API controller. The constructor is like this:
public class AccountController : ControllerBase
{
private readonly IBlazorSignInManager _signInManager;
private readonly IBlazorUserManager<AppUser> _userManager;
public string ErrorMessage { get; set; } = string.Empty;

public AccountController(IBlazorSignInManager<AppUser> signInManager, IBlazorUserManager<AppUser> userManager)
{
    _signInManager = signInManager;
    _userManager = userManager;
}

}
Any ideas or thoughts on where I should look?
Cheers,
Mark
Mark Nash
Senior Software Engineer
[cid:PC_42x23_fbb4e57e-65d2-4c41-b09e-ffa9f4a3c468.png]
PartnerComm, Inc.
Winner of 86 IABC Gold Quills
2022 Large Agency of the Year
2304 W Interstate 20, Suite 250
Arlington, TX 76017
[cid:pcomm25+_471933a4-f842-490b-84d4-910cf0397a29.png]
Office:<PHONE_NUMBER>
<EMAIL_ADDRESS>www.partnercomm.nethttp://www.partnercomm.net
This e-mail transmission may contain confidential information or may be otherwise legally privileged. If you are not the intended recipient you are hereby notified that any use, disclosure, copying, forwarding, or distribution of any of the information contained in or attached to this message is STRICTLY PROHIBITED.


omorfi: init at 0.9.9

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Could you please split into separate commits (libvoiko, hfst, omorfi, etc)?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2393

Result of nixpkgs-review pr 238378 run on x86_64-darwin 1

9 packages failed to build:

libvoikko
python310Packages.hfst
python310Packages.hfst.dist
python310Packages.omorfi
python310Packages.omorfi.dist
python311Packages.hfst
python311Packages.hfst.dist
python311Packages.omorfi
python311Packages.omorfi.dist

Marked Darwin to be broken now.

Result of nixpkgs-review pr 238378 run on x86_64-linux 1

12 packages built:

hfst
hfst-ospell
libvoikko
omorfi
python310Packages.hfst
python310Packages.hfst.dist
python310Packages.omorfi
python310Packages.omorfi.dist
python311Packages.hfst
python311Packages.hfst.dist
python311Packages.omorfi
python311Packages.omorfi.dist