Check out before burning

Address the comment in https://github.com/paritytech/polkadot-sdk/pull/2522#discussion_r1430503433
Resolves: SNO-800

https://github.com/Snowfork/snowbridge/pull/1071/commits/7c100640d1a9ed96afc723baba03fdca98882c23 to address the comment https://github.com/paritytech/polkadot-sdk/pull/2522#discussion_r1431464641

Not a priority to merge this now, can wait until Jan


pull request for e2e test at 01/23/2017 20:56:13

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Make importComponent work in test environments

I tried to implement support for importComponent  in test frameworks such as jest in hops.
While I had fun creating it, the resulting babel-plugin to "fix" the below mentioned issues has as many locs as the original importComponent's babel plugin.
It does not work out of the box, because importComponent relies on wepback being present.(require.resolveWeak and __webpack_modules__) are the ones in particular causing issues.
The __webpack_modules__ error ( ReferenceError: __webpack_modules__ is not defined) should be fixable by checking for its existence before accessing a value.
For require.resolveWeak, I suggest to add a test option to the babel plugin which will simply replace the require.resolveWeak with a 0 as moduleId. Afaik this should not cause any issues.
There's another issue, because the importComponent plugin adds an import statement which then won't be handled by babel-plugin-dynamic-import-node.  The following error is thrown instead: Jest encountered an unexpected token I tried to shuffle plugins around, but to no avail. I suppose it's some race condition? tbh I wonder how such issues don't happen more regularly with babel plugins, but I might just not understand them well enough yet.
Maybe we could also use Promise.resolve(require('whatever')) instead of using import when the test flag is passed?

@robin-drexler, while we have almost certainly discussed this before, could you be so kind as to explain why we cannot mock importComponent entirely and without transpilation?
Example:
const mockImportComponent = (path, name = 'default') => require(path)[name]

@dmbch afaik importComponent's api is a bit more flexible than just passing a path and an optional name. For example you can provide [a custom loader] prop (https://github.com/untool/untool/blob/master/packages/react/lib/runtime.js#L53) to the returned Component.
I'd like to have the mock resemble the real thing as closely as possible.
We could create a mock hoc that returns the actual Importer (if  that was available and we'd add a guard around __webpack_modules__)

@robin-drexler I am not quite sure I understand the goal here: one could easily test both loader and render separately, right? And those props would not be used anyway...

The goal is simply to keep the code that is run in tests as real as possible. Imo any mocking comes with a cost, especially if it's done implicitly and without any knowledge of the consumer.

one could easily test both loader and render

Yes, but it should in my opinion also be possible to the entire thing in its full beauty

And those props would not be used anyway...

Why wouldn't they? If I see it correctly, loading will indeed be used, because state.loading will initially be true: https://github.com/untool/untool/blob/master/packages/react/lib/runtime.js#L49

@robin-drexler I am still not convinced, really: in a Node.js environment, loading will never be true, so we will not be closer to reality if we do what you propose, as far as I can tell.
Let us see what the rest of @untool/core are saying, shall we?

The default jest environment is a dom-ish one, so I'd go with that as default.
I did not want to go as far as to detect the env we run in and behave differently based on that.
In any case an incomplete mock would already be an improvement to simply failing as soon as importComponent is used. Which is what currently happens.

I would say we ought to add the incomplete/minimal mock for now and iterate/enhance it if and when necessary. Should we add that mock here or over in xing/hops? Both options appear to have certain merits.

I'd also go for the minimal implementation because this function has — if I get this right — three features worth testing.

the actual inserting of an asynchrously loaded component
the displaying of a given loading state
the displaying of a given error state

Since we can I only provide one of those features deterministically inside test runs at a time, I would go with the first one: have the function do its basic job and not stand in the way of people wanting to test their application. For displaying optional loading or error states, peeps can easily roll their own mocks.
And since Hopsland is the realm of the Jest verlötung I'd add this mock function over there.

As discussed during the standup today, we'll go with the minimal approach implemented in Hops.


[feature request] dump the tx actions before the inline action depth reach the max depth

we occasionally got the error "max inline action depth per transaction reached" on executing our contract inline action which calling the third party contract, and it is hard for we to trace the action depth, can you add the logging feature to dump the tx on nodeos just before the inline action depth reach the max depth? or is there any exiting approach to locate the error?

Can you please share more specific information around your use case and the problem you are trying to solve? Thank you.

our contract invokes the third-party contracts which we do know their action depth is, so if action depth of our contract + action depth of third-party contracts, the tx would be failed without any actions details(coz the tx would be eosio::check(depth<10,"err msg"),so if the nodeos could dump the whole action depth before depth reach the max value, we could know what the actions depth is, it would help us turning the code to avoid the issue.

this error is too annoying, any progress on this issue?


Optional[date] behaviour is weird

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
I'm reporting this issue on V2 but I see weird behavior also in v1
I'll make different examples to explain it clearly.
The problem is: How can I define a non-required optional date field in my model? (I made an equivalent example for int and it works)
In theory, this can be achieved like this:
class LegitimateDateModel(BaseModel):
    date: Optional[date] = None

But I get a Validation error when I pass a value to the model
Example Code
from datetime import date
from typing import Optional

from pydantic import BaseModel

class LegitimateDateModel(BaseModel):
    date: Optional[date] = None

class LegitimateIntModel(BaseModel):
    x: Optional[int] = None

class LegitimateDateNotRequiredModel(BaseModel):
    x: Optional[int]

LegitimateDateModel(date=date(2020, 1, 1))  # ValidationError: Input should be None. I got same error in v1 as-well
LegitimateDateModel()  # date is None and everything is OK
LegitimateIntModel(x=1)  # x = 1. Everything is OK

Python, Pydantic & OS Version
pydantic version: 2.4.2
        pydantic-core version: 2.10.1
          pydantic-core build: profile=release pgo=false
                 install path: /Users/sabersolooki/.pyenv/versions/3.11.4/envs/pydanticplay-v2/lib/python3.11/site-packages/pydantic
               python version: 3.11.4 (main, Jun 20 2023, 16:51:49) [Clang 14.0.0 (clang-14<IP_ADDRESS>)]
                     platform: macOS-12.4-x86_64-i386-64bit
             related packages: typing_extensions-4.8.0

Hi @saber-solooki,
Thanks for reporting this. The problem here is that your field date is named the same as the type date. You can fix this with the following change, or some similar modification:
from datetime import date
from typing import Optional

from pydantic import BaseModel

class LegitimateDateModel(BaseModel):
    date_: Optional[date] = None

or
from datetime import date as date_
from typing import Optional

from pydantic import BaseModel

class LegitimateDateModel(BaseModel):
    date: Optional[date_] = None

@sydney-runkle Thanks it works. I thought it might be a bug since it is working in v1

from datetime import datetime
from typing import Optional
class MyModel(BaseModel)
issue_date = Optional[datetime]
Above code in v2 raises error :
pydantic.errors.PydanticUserError: A non-annotated attribute was detected: issue_date = typing.Optional[datetime.datetime]. All model fields require a type annotation; if issue_date is not meant to be a field, you may be able to resolve this error by annotating it as a ClassVar or updating model_config['ignored_types'].


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-yml-archive-non-versioning-archive/pull/287 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-yml-archive-non-versioning-archive.git

Docs Build status updates of commit da11697:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

docs/TOC.yml
:white_check_mark:Succeeded
View

docs/index.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-3.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/sql-database-engine.png
:white_check_mark:Succeeded

docs/to-be-archive/level2/article3-2-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-3.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Usage of OpenDAL for database

Usage of OpenDAL may relevant to be able to use various backend.
It may ask the question to have database trait that may be implemented by SQLX (with SQlite), or SQLX (with Postgres, etc.) or by OpenDAL with custom backend.
It open also to be able to use oxigraph as backend to store semantic data ;-) (I have already done that for one of our backend)

Interesting, I didn't know this existed. It looks like it can readily replace the current storage layer that abstracts over either the FS or S3. And can be used for other kind of backends as well.