Get-PnPTenantSite : System.InvalidOperationException: The type of data at position 1684 is different than the one expected.

Hi,
When try to obtain the PnPTenantSite information exception is thrown. Seems, it is related to parsing of the JSON result received from O365. I have checked the traffic with fiddler and it seems that the result coming from O365 is correct.
Category

[ ] Question
[ ] Typo
[x] Bug
[ ] Additional article idea

Steps to reproduce behavior
Execute 'Get-PnPTenantSite' cmdlet with or without parameters.
Expected behavior
Receive TenantSite / List of TenantSite objects.
Actual behavior
Exception is thrown:
System.InvalidOperationException: The type of data at position 1687 is different than the one expected.
at Microsoft.SharePoint.Client.JsonReader.ReadGuid()
at Microsoft.Online.SharePoint.TenantAdministration.SiteProperties.InitOnePropertyFromJson(String peekedName, JsonReader reader)
at Microsoft.SharePoint.Client.ClientObject.FromJson(JsonReader reader)
at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream)
at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse()
at Microsoft.SharePoint.Client.ClientRequest.d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SharePoint.Client.ClientRequest.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SharePoint.Client.ClientRuntimeContext.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.SharePoint.Client.ClientContext.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at Microsoft.SharePoint.Client.ClientContextExtensions.d__7.MoveNext()

This seems related to the PnP Core PowerShell component... best to submit this question to that specific repo's issue list: https://github.com/SharePoint/PnP-Sites-Core

It is not related to PnP Core Powershell. Teh exception is coming from Microsoft.SharePoint.Client.JsonReader.ReadGuid().
Please reopen.

The issue is in the underlying CSOM APIs or specifically in the server side APIs and is being worked on. Path deployment should get on hold and canceled so we should not have new tenants experiencing this anymore. The fix is being worked on and it will be shipped server side as soon as possible, but can't provide an exact ETA at this point.
Thanks for reporting this.

Thank you very much for addressing this.   Have a client tenant that is adversely affected by this bug.   Thanks again.

This is affecting both our Live and Production tenancy's with this issue.

@VesaJuvonen any ETA / updates? We have many customers who are all having this problem when provisioning sitecollections.

We do have several customers, along with different DEV/ TEST and PROD tenants who are affected  when provisioning site collections.

Thanks for the clarification, @VesaJuvonen ! I can also confirm we have several environments being affected by this issue, so we are eagerly awaiting new updates :)

Thanks, everyone for following up on this with updates. I'll try to get the latest status from owners of the issue and share it here asap.

We are being impacted as well with Azure Automation scripts that have a dependency on this functionality.

Have they considered backing out the changes on the affected Tenants, until they have a fix?

Have they considered backing out the changes on the affected Tenants, until they have a fix?

+1 What he said.

Our production and development tenants suffered this problem on March 12 - 13, but now it is no longer an issue as of March 14th.

I do not have yet ETA for this, but things are actively being worked on. Thanks, everyone for the updates as they do help others to see how things are progressing cross the tenants. Transparency will reduce confusion.

Our production and development tenants suffered this problem on March 12 - 13, but now it is no longer an issue as of March 14th.

Per what spkimc also just mentioned, my client's tenant that was experiencing the issue 12th & 13th is also no longer experiencing it today (the 14th).  Obviously no idea if that is a roll back or a fix, but its working for now so thank you very much for the support and communication.

The fix is currently being rolled out worldwide, so the issue should be resolved for everyone within upcoming hours. Please do provide updates on your tenant status. If the issue still exists after a few hours, please do report that in here as well. Thanks, everyone for your activity on this.

It is working again. Thanks for the fix.

Yesterday I had this error at the beginning of script when creating a site collection app catalog.  This line, $ctx.ExecuteQuery(), caused this error:
Exception calling "ExecuteQuery" with "0" argument(s): "The type of data at position 1144 is different than the one expected."
Today, I have been successful in passing the above point in the scripts and in building a hierarchy of 6 sites but right near the end of my scripts I see it again when I am turning off minor versioning on the site pages library:  Invoke-PnPQuery : The type of data at position 1145 is different than the one expected.
While the minor versioning is successfully turned off but this Invoke-PnPQuery is returning the above error every time.

All working again in both Production and Dev tenancy's. Many thanks for the fix and updates.

It is working on my tenants as well. @VesaJuvonen thank you for your help!

Get-PnPTenantSite seems to work ok now, but, you cannot create sitecollection with "publishing portal" template from admin center UI, the task never ends. To create classic teamsite, it works ok. So something to do still with activating publishing feature?
trying to create publishing portal:

teamsite create ok:

@VesaJuvonen, fix doesn't seem to be rolled out to the tenant of one of our customers and it's really big problem for us, because CSOM in our app stopped working. I can send you more details about tenant, so you can verify it.

I can also see issue still on my tenant.

Thanks, everyone on your status updates. I'll check things internally and try to get back asap. The update is rolling out gradually, so having some tenants already working and some don't, is understandable.

Quick update - Fix is still in progress to get fully rolled out, so it's understandable that some have this already fixed and it's still an issue in some tenants. The situation should be fully resolved within the next 12 hours unless there are unexpected delays.

We are not seeing the error anymore but are getting intermittent time outs on Get-PnPTenantSite, GetSPOSite...

@VesaJuvonen, unfortunately the bug is still there.

My tenant is fixed.

My tenant's fixed

We got the error when creating a Teams from an existing Group. The error is gone, but now we are getting this error instead:
{
"error": {
"code": "BadRequest",
"message": "Entity only allows writes with a JSON Content-Type header.",
"innerError": {
"request-id": "0912aea8-c336-49e4-9a68-e38f0dc5577b",
"date": "2019-03-18T11:36:35"
}
}
}

Still getting the error as well.
We have had this issue for a week.  When is it going to be fixed?

I can confirm that this issue has been fixed on all 2 of my tenants where I saw this. While we're still experiencing issues with site provisioning, I suppose they're not connected to this particular change?

@koskila @tavikukko  we also have problems with the site provisioning of Publishing Portals, we get the same error as @tavikukko  and the site never gets created. I created a site collection without a template and tried to apply the publishing portal template after creating, but I got the following error:

Probably related to this:

The deployment of the fix is scheduled for 23 March, which is very late, regarding that it is impossible to create new site collections for nearly two weeks now. Can't it be deployed any sooner?

My affected tenant was finally patched.

All good here too

We do understand that this was far from the optimal situation, but thanks for following up with the status updates. Based on our patch tracking, the issue should be now resolved worldwide, so closing this one. We do apologize for the inconvenience caused by this issue and are working on actions to prevent similar issues in the future.


Complete tests for chttp.New() function

Codecov Report

Merging #33 into master will increase coverage by 2%.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #33   +/-   ##
=======================================
+ Coverage   89.43%   91.44%   +2%
=======================================
  Files          19       19
  Lines        1297     1297
=======================================
+ Hits         1160     1186   +26
+ Misses        116       91   -25
+ Partials       21       20    -1

Impacted Files
Coverage Δ

chttp/chttp.go
85.61% <100%> (+15.75%)
:arrow_up:

chttp/auth.go
61.61% <0%> (+3.03%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e5d789d...037bfeb. Read the comment docs.


Unable to login

From Robin via customer support:
Steps in the video:

Sign in through browser successfully using the password.
Try signing in to the app using the same password,  but fails.

Feel free to let me know if you need any assistance with further debugging or more info on reproducing the issue or if you like to get on a video call.
It's 100% reproducible, at least on my S21+ , Android 13 device.
https://github.com/razeware/emitron-Android/assets/658798/9423fc30-9504-4b81-9d23-8370778e185e

Hi @sammyd I'm having difficulties reproducing the issue. I'm using a Samsung Galaxy A53 5G. Below was the output presented here. Can you also confirm if, after signing in, you wait for some seconds on the login screen to what it shows?
From what I observed, if you wait for some seconds it eventually signs up successfully. Here is my output on my device.
https://github.com/razeware/emitron-Android/assets/36895007/4b8e113e-d06a-4184-b958-7e1a3d428a01

Thanks for taking a look. I'm not too sure about this—I've not managed to recreate it myself.
I'll go back to the support ticket and see whether I can get the reporter to come and look at this ticket to give some additional feedback. The only thing I know has been an issue before is the default browser.
I'd also be interested in knowing why it flashes the login screen again, or more importantly, can we stop that and replace it with some kind of spinner?

That will be very much helpful. In regards to re-opening the login screen that shouldn't happen though i haven't looked at the code yet but a spinner or something else will be much better.

Any comments here from the reporter?

Nope, they've not been back in touch :(

Hello @sammyd , I'm the reporter of the issue.
There is difference in the two videos. When I clicked, you can see, it does go into raywenderlich domain momentarily which doesn't happen in the 2nd video.
My account was created more than 3 years ago while website was still with raywenderlich, hope that's some clue.

Hi @robinjohn thanks for dropping in! I don't think that the fact your account is old should have any issues. @KelvnPere are you able to help diagnose the issue here? Thanks!

Thanks for providing more context @robinjohn

Hi @KelvnPere,  happy to share my account password if you're not able to reproduce the issue,  let me know. Thanks.


move init code from SYS_INIT to hooks (first pass)

reduces number of SYS_INIT usages from 171 to 34 under soc/

init: enhance kconfig docs for custom hooks
soc: adi: move init code from SYS_INIT to hooks
soc: ambiq: move init code from SYS_INIT to hooks
soc: andestech: move init code from SYS_INIT to hooks
soc: arm: move init code from SYS_INIT to hooks
soc: atmel: move init code from SYS_INIT to hooks
soc: brcm: move init code from SYS_INIT to hooks
soc: ene: move init code from SYS_INIT to hooks
soc: gd: move init code from SYS_INIT to hooks
soc: intel: move init code from SYS_INIT to hooks
soc: lowrisc: move init code from SYS_INIT to hooks
soc: microchip: move init code from SYS_INIT to hooks
soc: nuvoton: move init code from SYS_INIT to hooks
soc: nxp: move init code from SYS_INIT to hooks
soc: openisa: move init code from SYS_INIT to hooks
soc: quicklogic: move init code from SYS_INIT to hooks
soc: renesas: move init code from SYS_INIT to hooks
soc: sifive: move init code from SYS_INIT to hooks
soc: silabs: move init code from SYS_INIT to hooks
soc: snps: move init code from SYS_INIT to hooks
soc: st: move init code from SYS_INIT to hooks
soc: telink: move init code from SYS_INIT to hooks
soc: ti: move init code from SYS_INIT to hooks

@jhedberg  @henrikbrixandersen  thanks for the review, fixed now. When you are in the forest, you do not see the tree ;-(

STM32WB0 series is missing (recent addition).

there are many things missing or left on purpose, we will do a second pass with  the remaining SoCs


fix: LSDV-5343: Docs for visibleWhen; fix for incorrect whenChoiceValue

Hi @hlomzik!
This PR was created in response to a PRs in upstream repo:

https://github.com/heartexlabs/label-studio-frontend/pull/1483

/git merge develop


Consider avoiding unnecessary cloning by traversals

Currently traversals such as L.elems and L.values, when used through e.g. L.modify, do not attempt to detect when the result is actually equal to the input.  For example,
L.modify(L.elems, x => x, xs)

effectively clones the xs array (assuming it has no undefined elements).  Given that we are dealing with immutable data structures, it would be possible to do a shallow equality comparison to detect when the output would be the same as the input and return the original input instead.
Note that e.g. the standard xs.map(x => x) also clones the array, which is also unnecessary assuming one is dealing with immutable data structures.
Of course, adding such detection directly to the implementation of L.elems slows it down. In some benchmarks it seems that e.g. L.modify(L.elems, x => x+1, xs) slows down by up to about 25%. That should be close to the worst case.  Also, the slowdown only applies to operations that return the modified data structure (e.g. L.set, L.remove, L.transform) and does not apply to folds over traversals.
It can also be done as a separate pass, e.g.
const unclone = (x, i, C, xi2yC) =>
  C.map(y => {
    const n = y.length
    if (x.length !== n) return y
    for (let i = 0; i < n; ++i) if (!I.identicalU(x[i], y[i])) return y
    return x
  }, xi2yC(x, i))

but that has much higher overhead.
It is not entirely clear whether adding the cloning avoidance is worth it, but there are definitely cases where cloning avoidance would be a nice to have feature.  Currently I'm leaning more towards changing the implementation to avoiding cloning.  That is because I have now several applications of optics where cloning avoidance would be advantageous.  There also seem to be no other downside to cloning avoidance except for the performance hit, because Partial Lenses do not support the use case of mutating data structures returned by optics operations.
Feedback and 👍 or 👎 votes are welcome!

As of version 13.10.0, cloning avoidance has now been explicitly sanctioned, but not guaranteed.  When an operation uses the Identity applicative (this includes the L.modify, L.set, L.remove, and L.transform operations), the L.elems and L.branchOr (and variations of it) traversals currently avoid unnecessary cloning.


Respone content is missing from default exception output

Currently the content of the error response in a WebRequestException is a custom proprety (Response). Most logging frameworks will call ToString() or log the Message property. ToString by default concatenates the Message and StackTrace properties.
At its current state the WebRequest exception will output the ReasonPhrase and StackTrace. The reason phrase is usually Bad Request or the odd Not Found making it very hard to trace. We had to revert to transforming the Exception to a wrapper type to have or logger handle it properly.
I can provide a PR with either of:

Concatenate the response to the message
Override ToString to add the response

This could be by default or it could be optional based on a new Settings property.
Let me know how you want to proceed.

Perhaps the best would be to control the behavior via additional Settings property, but what should be default? If response content is not large in majority of cases, then attaching to a message can be default. I am skeptical to overriding ToString to keep ToString output smaller.

I guess the size depends on the backend. Microsoft CDS (PowerApps/Dynamics365) for example outputs the actual error message plus the stack trace on the server which sizable.

I think perhaps another suggestion would be to control it by providing a delegate of type Func<HttpResponseMessage,WebRequestException> to override the default exception construction and let the consumer handle it.

I think perhaps another suggestion would be to control it by providing a delegate of type Func<HttpResponseMessage,WebRequestException> to override the default exception construction and let the consumer handle it.

IMHO this would be unnecessary complex. Creating a delegate just to override message written on exception. I'd stick to Settings property controlling what should be written in a response and consider delegate option only when there is an actual use case that requires exception management.

Ok so an option to control the output it is. I suggest an enum for clarity .
ExceptionMessage
{
ReasonPhrase,
ResponseContent
}
There could be a third option to concatenate the two.

And if not set, default would be phrase, like today? Looks reasonable.
Should we call this enum WebRequestExceptionMessage? With cases:

IncludeReason
IncludeResponse
IncludeAll
or define only two but define enum as flags so they can be combined? If you prefer to keep origina names (ReasonPhrase and ResponseContent) that is fine for me too.

It's just three cases so its clean and simple, flags would just add syntactic complexity without benefit imho.
I prefer the original names for consistency with Microsoft's Http notations, after all its a WebRequestException so the logical relation is clear .

It's just three cases so its clean and simple, flags would just add syntactic complexity without benefit imho.
I prefer the original names for consistency with Microsoft's Http notations, after all its a WebRequestException so the logical relation is clear .

Then go ahead :-) Agree about extra complexity added with flags.

@object I noticed this wasn't included in the last release, any for the next release?

Hmm, I believe it was. Check here:
https://www.fuget.org/packages/Simple.OData.V4.Client/5.12.0/lib/netstandard2.0/diff/5.11.2/

Ok intellisense crapped out, a clean and rebuild fixed it, sorry about the the fuss.


relax node and iojs restrictions

Trying to get rid of warnings. Related to https://github.com/karma-runner/karma-cli/pull/10 .

CLA was signed

Thanks for the contribution! Could you explain in more detail what warnings you are getting and why you are reintroducing the iojs field (The last conversation about this that I read was that this shouldn't be used and npm would ignore it)

npm WARN engine<EMAIL_ADDRESS>wanted: {"node":"~0.8 || ~0.10"} (current: {"node":"0.12.4","npm":"2.11.0"})

These changes here shouldn't be needed, see my comment on the other PR.


ollama llm vision api call error:     async for raw_chunk in stream_resp: TypeError: 'async for' requires an object with aiter method, got bytes

Bug description
when running any vision llm call (like example/llm_vision.py)
there seems to be an issue with async def _achat_completion_stream(self, messages: list[dict], timeout: int = USE_CONFIG_TIMEOUT) -> str: method
Bug solved method
No solve yet
Environment information
system metal, llm ollama, Python 3.10.13

LLM type and model name: ollama, llava latest

System version:

Python version: Python 3.10.13

MetaGPT version or branch: main

packages version: /

installation method: from source

Screenshots or logs
.....
do = self.iter(retry_state=retry_state)
return fut.result()
return self.__get_result()
raise self._exception
result = await fn(*args, **kwargs)
return await self._achat_completion_stream(messages, timeout=self.get_timeout(timeout))
async for raw_chunk in stream_resp: (HERE)
TypeError: 'async for' requires an object with aiter method, got bytes

@ten2mushi
Thank you for your feedback!
To better understand and reproduce the issue, could you please provide more complete code? Specifically, a minimal reproducible code snippet or sample project would greatly help us in identifying the problem more efficiently. Thank you for your cooperation!

Hi @ten2mushi,
I've reproduced this error, and it appears to be a conflict between the Ollama streaming call stack and async handling. Setting stream: false in config2.yaml::llm should help prevent this error.

Thanks for looking into it!
I've tested the change in config (stream set to false) in a fresh install of the repo.
This throws another error when running llm_vision.py:
assert assist_msg.get("role", None) == "assistant"

AssertionError

@better629 @EvensXia Can you guys take a look?

I just merged the related PR, you can try again.


pyupgrade --py38-plus

[ ] Closes #xxxx .
[ ] I am familiar with the contributing guidelines.
[ ] Tests added.
[ ] Updates entries to docs/source/api.rst for API changes.
[ ] Adds descriptions to appropriate "what's new" file in docs/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
[ ] New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
[ ] Maintainer: Appropriate GitHub Labels and Milestone are assigned to the Pull Request and linked Issue.

I recently learned about pyupgrade and thought I'd throw it at solarforecastarbiter to see what it catches. Mostly improvements, not sure about the doc formatting and the IOError vs. OSError.
pyupgrade --py38-plus solarforecastarbiter/**/[a-z]*.py

The changed documentation renders the same as it currently does on master.
IOError --> OSError is https://www.python.org/dev/peps/pep-3151/
Not sure what's up with the coverage failure but I think it can be overlooked.


feat: Re-introduced Aztec CLI

This PR reintroduces the Aztec CLI for use against deployed environments. It also contains deployment and other fixes for an initial devnet.

Benchmark results
Metrics with a significant change:

protocol_circuit_witness_generation_time_in_ms (root-parity): 64.7 (+35%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.
| Metric |  |
| - |  |
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,452
9,476
9,464

l1_rollup_execution_gas
616,093
616,117
616,105

l2_block_processing_time_in_ms
1,285 (-2%)
4,816 (-1%)
9,576 (-1%)

l2_block_building_time_in_ms
45,407 (-1%)
180,406 (-1%)
360,937 (-1%)

l2_block_rollup_simulation_time_in_ms
45,231 (-1%)
179,754 (-1%)
359,646 (-1%)

l2_block_public_tx_process_time_in_ms
24,381 (-1%)
102,258 (-1%)
209,385 (-1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
9,416 (-2%)
14,387 (-1%)

node_database_size_in_bytes
14,438,480
21,303,376

pxe_database_size_in_bytes
18,071
29,868

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Circuit
simulation_time_in_ms
witness_generation_time_in_ms
proving_time_in_ms
input_size_in_bytes
output_size_in_bytes
proof_size_in_bytes
num_public_inputs
size_in_gates

private-kernel-init
132 (-1%)
501
12,115 (+1%)
20,634
64,614
89,536
2,731
524,288

private-kernel-inner
406
1,024 (+2%)
40,609 (+3%)
92,326
64,614
89,536
2,731
2,097,152

private-kernel-tail
578 (-1%)
3,039 (+1%)
36,761
96,545
77,732
11,648
297
2,097,152

base-parity
6.58
1,268 (-1%)
2,889
128
64.0
2,208
2.00
131,072

root-parity
49.8
:warning: 64.7 (+35%)
44,249 (+1%)
27,100
64.0
2,720
18.0
2,097,152

base-rollup
748 (+3%)
2,334
74,391 (-1%)
119,738
756
3,648
47.0
4,194,304

root-rollup
112
65.4 (+2%)
19,194 (-1%)
25,309
620
3,456
41.0
1,048,576

public-kernel-app-logic
532 (-1%)
3,150 (-2%)
47,962 (-1%)
105,257
86,550
116,768
3,582
2,097,152

public-kernel-tail
1,114 (-1%)
21,566 (-10%)
154,994
401,006
7,646
11,648
297
8,388,608

private-kernel-reset-small
586 (-1%)
2,131 (-4%)
45,505
120,737
64,614
89,536
2,731
2,097,152

merge-rollup
28.7 (-1%)
N/A
N/A
16,542
756
N/A
N/A
N/A

public-kernel-setup
642 (-3%)
N/A
N/A
105,257
86,550
N/A
N/A
N/A

public-kernel-teardown
542 (-4%)
N/A
N/A
105,257
86,550
N/A
N/A
N/A

private-kernel-tail-to-public
N/A
8,591
90,759 (-1%)
N/A
N/A
116,768
3,582
4,194,304

Stats on running time collected for app circuits

Function
input_size_in_bytes
output_size_in_bytes
witness_generation_time_in_ms
proof_size_in_bytes
proving_time_in_ms
size_in_gates
num_public_inputs

ContractClassRegisterer:register
1,344
9,944
469 (-1%)
N/A
N/A
N/A
N/A

ContractInstanceDeployer:deploy
1,408
9,944
42.2
N/A
N/A
N/A
N/A

MultiCallEntrypoint:entrypoint
1,920
9,944
1,454
N/A
N/A
N/A
N/A

SchnorrAccount:constructor
1,312
9,944
997 (+1%)
N/A
N/A
N/A
N/A

SchnorrAccount:entrypoint
2,304
9,944
2,114
16,768
48,964
2,097,152
457

Token:privately_mint_private_note
1,280
9,944
1,148 (+1%)
N/A
N/A
N/A
N/A

Token:transfer
1,376
9,944
4,091
16,768
46,146 (-1%)
2,097,152
457

Benchmarking:create_note
1,312
9,944
954
N/A
N/A
N/A
N/A

FPC:fee_entrypoint_public
1,344
9,944
228 (+1%)
N/A
N/A
N/A
N/A

SchnorrAccount:spend_private_authwit
1,280
9,944
78.0 (-6%)
N/A
N/A
N/A
N/A

Token:unshield
1,376
9,944
3,297 (+1%)
N/A
N/A
N/A
N/A

FPC:fee_entrypoint_private
1,376
9,944
4,067 (+1%)
N/A
N/A
N/A
N/A

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.5
17.0
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.7
31.8
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.607
0.522
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
48.7 (-1%)
76.2 (-1%)
247
474 (-1%)
933 (-1%)
1,849
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.498
0.470
0.448 (-1%)
0.443 (-1%)
0.442 (-1%)
0.441
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
58.3
112 (-2%)
357
698 (-1%)
1,390 (-1%)
2,772
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
106
208
692
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.505
0.504 (-1%)
0.484
0.479 (-1%)
0.481
0.481
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
62.6 (-1%)

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
107

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.555 (-1%)

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
84,050
665,267

Transaction size based on fee payment method
| Metric |  |
| - |  |


Support Vec4

This is a common format for some game data and should give similar performance to Vec3A.

The bounding spheres should also use Vec4 instead of Vec3A + f32.

Performance is identical with the new generic functions other than a small 20% regression on x86 (Ryzen 3700x) for tangent calculations. This should be offset by applications no longer needing to allocate a new vector of Vec3A.


Issue 47

Ticket #47
Description
Add basic analytics to website
Screenshots / Demo Video
Data being tracked: (you can see the one user in the last 30 minutes which was me)

Here is the google analytics ID and code to be put in the index.html file which matches the changes being commited

Testing
Tested on my local by opening multiple instances of the website in incognito tabs which all tracked as separate users visiting the website
Checklist

[x ] Provided ticket and description
[ x] Your PR title contains the ISSUE ticket number e.g "86: ..."
[ x] Provided screenshots/demo
[ x] Provided testing information
[ x] Provided adequate test coverage for all new code
[ x] Added PR reviewers
[ ] Ensure at least 1 review before merging

going to redo this PR a little cleaner


Weird behavior with intellisense autocomplete

The autocomplete get's appended to already typed letters if they were changed by the extension.
For example
if (a.foo) {
  b('Foo', a.foo);
}

results in
if (a.bar) {
  b('Babar', a.bar);
}

when I accept a.bar autocomplete suggestion after typing two letters.

Yea, true. It never bothered me, so I haven't tried to do anything about it. I might give it a go in the future or accept a PR. There is probably no API to detect autocomplete, as is the case for paste and undo/redo. You'd have to find a reliable way to detect autocomplete happening from text alone.


Antepenultimate or Controller-related commits

These deal with the issues that I brought up earlier.

The first two commits are tweaks and refactorings.

The third one is quite significant - collection.Collection.index is now a property, but actually, the whole "Collection that has a current_animation" idea got spun off into a separate class, collection.Indexed.
Collection got too big with this new change, and I think you'll agree it makes no sense for Parallel and Split - which use multiple animations at once! - to have any idea of current_animation.
I didn't just do this to be annoying :-D - I need to be able to say .animation.index = 0 in the control, and have all the loading of the new image, debug logging of the name, etc occur automatically.

And finally, we add a thread-safe event queue to the project.  It's unfortunately only thread-safe with respect to the animation engine, not to the driver engine, so it does not solve the "brightness" issue as I originally advertised!  Oh, well.
It came out nicely.  If you wanted to go right to the event queue suddenly in client code you'd write something like:
project.deferred_set(Address('.animation.index'), 0)

which would set project.animation.index to 0 at the start of the next rendering frame!

Ah, hold off on this for a bit.  I have a couple of last tweaks, and I just pushed some partial commits to the end of this by mistake...!

All right!  This actually does something!!!
I rearranged things considerably.  :-D
Now the first four commits are basically trivial.
Then the split-up of collection.Collection - fun fun.
A series of commits to the Project - adding an event queue, fixing a parser bug, and moving the start and cleanup logic out of main/run.py and into project/project.py.
Then there's a big deal - a final change to Address.  I realized that a lot of the time, when I trigger on some event, at the end of routing I am left with ()!  So I need a way to add preset values for that very common case - and I did it with the = sign so you say things like animation.index = 1, which seems pretty clear to me.
  However, there's nothing really alien in there, just a bunch of small  tweaks...

Ping!

Me too!  I hope to get out a video with using a fader box and the 12k this week ..... :-o


Treewide: clock control API minor casting enhancement

Is your enhancement proposal related to a problem? Please describe.
The clock control driver is currently used treewide like:
clock_control_on(clock_dev, (clock_control_subsys_t *)&cfg->clock_cfg);
clock_control_get_rate(clock_dev, (clock_control_subsys_t *)&cfg->clock_cfg, &rate);

Where the clock_control_subsys_t is an opaque type which the API expects
typedef void *clock_control_subsys_t;
// ...
typedef int (*clock_control)(const struct device *dev,
			     clock_control_subsys_t sys);

typedef int (*clock_control_get)(const struct device *dev,
				 clock_control_subsys_t sys,
				 uint32_t *rate);

Describe the solution you'd like
s/(clock_control_subsys_t *)/(clock_control_subsys_t)/ for all uses of the clock control API.

Architecture WG:

@pdgendt states that is already a mix of usage with and without asterisk in-tree
@henrikbrixandersen states that this is different from #49333 because the API is left untouched
Does not require any changes to out-of-tree because using with or without asterisk does not trigger warnings
@galak agrees this is a worthwhile cleanup
Agree to squash the commits
No objections in the call

Note that typedef could be left as is, deprecated, but all its usages/function signatures updated without creating a breaking change. I think it's worth considering this option now that we touch dozens of files for a typedef that doesn't make any sense.

I didn't change the typedef in the PR.

Note that typedef could be left as is, deprecated, but all its usages/function signatures updated without creating a breaking change. I think it's worth considering this option now that we touch dozens of files for a typedef that doesn't make any sense.

I didn't change the typedef in the PR.

I know, just suggesting that cleanup could remove typedef usage entirely, use void * in functions, but keep the typedef for OOT users, so change doesn't break their code.

I know, just suggesting that cleanup could remove typedef usage entirely, use void * in functions, but keep the typedef for OOT users, so change doesn't break their code.

That would touch a lot more files, and casting to void * would still need to be done with all the API calls to avoid compiler messages like:
warning: passing argument 2 of 'clock_control_on' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
# or
note: expected 'void *' but argument is of type 'const struct atmel_sam_pmc_config *'


[Service Bus] Merge feature/service-bus-atom branch to master

This issue is for tracking efforts on final merge PR and other final things that may be necessary to get to releasing feature from master branch.

Closed with #6893


[issue-225] Source and target java8

Using java13 before the PR:
java -version # `openjdk version "13.0.2" 2020-01-14 `
sbt package
cd target/scala-2.11
unzip rediscala_2.11-1.9.0.jar
javap -verbose redis/util/CRC16.class | grep version # major version: 57

After the PR:
java -version # `openjdk version "13.0.2" 2020-01-14 `
sbt package
cd target/scala-2.11
unzip rediscala_2.11-1.9.0.jar
javap -verbose redis/util/CRC16.class | grep version # major version: 52

It has also been tested in production with our Java 8 backend.
Thanks for the project, we really appreciate it!
Should fix #225

@etaty Sorry for pinging you again for the exact same issue :)
I have made this PR as this is probably the minimal line of code to make sure this is compatible with java8 +.
Let me know if there is anything I can do. Thanks

@etaty Sorry for pinging you again for the exact same issue :)
I have made this PR as this is probably the minimal line of code to make sure this is compatible with java8 +.
Let me know if there is anything I can do. Thanks

Coverage decreased (-0.06%) to 90.386% when pulling c97ed3779c402df0f70639879f1bd5d50d4cadc0 on bluesheeptoken:fix-issue-225 into 5600b0023c44fea410afe6c7d2d89b6ec26a0533 on etaty:master.

Coverage decreased (-0.06%) to 90.386% when pulling c97ed3779c402df0f70639879f1bd5d50d4cadc0 on bluesheeptoken:fix-issue-225 into 5600b0023c44fea410afe6c7d2d89b6ec26a0533 on etaty:master.


add CHANGELOG

Please add that we have improved the output cli results. Now we provide brief summary of all the problems grouped by severity level.

Please add that we have improved the output cli results. Now we provide brief summary of all the problems grouped by severity level.


Hi, Sir! When will the Tensorflow code be released?

(What the title says)

Hi A1exy,
I'm running some final tests on a PyTorch implementation of Deep SVDD that will be more comfortable to use.
I'll link to the repo once it goes public and I plan to so this week.


Fix backdrop animation by adding .swal2-shown class asynchronous

Fixes #650

This PR fixes the backdrop animation for single modal, but unfortunately, there's a regression for chaining modals - the backdrop is flickering.

@limonte A solution to this would be to separate the backdrop element from the swal2 container. This way a backdrop could remain in the DOM while in a chaining modal state.
If you agree that this is a viable option, I'm happy to write the code for it!

Go ahead @acupajoe :rocket: , separating the backdrop element from the swal2 container might be the proper way to fix the issue.

@limonte I think that will do it!

Many thanks @acupajoe! The fix looks exactly like we were planning. The only one thing I'm not 100% happy is related to UX. There's the noticeable delay between closing the modal and closing the backdrop.
As a user, I want to be able to work with my document asap after I clicked a button in the modal window.
Give me 2-3 days to review this PR, I think I have a simple solution in my mind, but I'm can't visualize it completely :)
Thanks again and have a great working week!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Colour map cluster markers by fresh data recording

Is your feature request related to a problem? Please describe.
We would like to have the map markers and cluster markers coloured orange/grey depending on whether the location received data in the last 24 hours, instead of using the active flag [which only means that there is a device registered there but not necessarily turned on].
Describe the solution you'd like
At map loading, make an API call for the last 24hrs of data for each active device [don't call for inactive locations!] and create a client-side callback that will render the colouring based on whether data is available for any location in the given cluster. See the admin page for a hacky implementation of something similar but the loading time there is very slow so one needs to test a reasonable fast solution.

See Example 3 here for caching server-side globally.

This has been recently addressed but we need to look into improving the increased load times due to calling the API for each location separately.


Fix / silence warnings

Closes #22
Most warnings were genuine.

scala-collection-compat provides the @nowarn annotation, which the Silencer SBT plugin is picking up  under Scala 2.12, allowing us to support the new syntax under 2.12.

Usage of Circe emits warnings like 'Block result was adapted via implicit conversion (method apply) taking a by-name parameter' under Scala 2.13. This changeset sets up warning options to silence all of these.

Nice to have a clean build!


Removed article the from text

Hello, just a small typo (?). Not sure if the correct one is "the" or "your" I went for "your". Hope it is ok :D

Haha, perfectly okay! :)


⚠ Bofrost.es has degraded performance

In 400e02b, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1414 ms

Resolved: Bofrost.es performance has improved in 61c7df0 after 7 minutes.


Update the French translation

Currently WIP.
I wanted you to have a way to track this. :)

I'll squash the commits when it's ready for merging.

This is almost done, I'll be doing some proofreading and then putting the PR into ready for review.

This should be ready for review now. :D

(Review is pretty much just making sure nothing weird is visibly in there, I definitely can't check the correctness lol)
Thank you!

... Welp, lesson learned, next time there's a language PR I will have to add "run a JSON validator over it" first.
Please do test that things look correct in-UI btw, would've caught that particular error (by way of the UI failing to boot apparently) and could catch other slips.

oops :3


fix animation

This incorporates the animated image into the main window

You could do a one-liner ternary if you felt fancy, like this:
@logo.path = (frame.to_i.even? : "Resources/audiorecorder_small_3.png" : "Resources/audiorecorder_small_2.png")

Although if it's too big for one liner here, it's probably not meant to be. ;)

Merci! Good to know!


[ssr] invalid locations error when using server only templates

Which package(s) are affected?
SSR (@lit-labs/ssr)
Description
Per this thread on use cases for Lit SSR, the takeaway was that a special server only template function has now been made available that would relax some of the restrictions on the client side version of html, thus allowing something like this to be server rendered now
import {render, html} from '@lit-labs/ssr';

const template = ({ title, lang }) => html`
  <!DOCTYPE html>

      <title>${title}</title>

${title}

`;

However, based on my experiments
import { render, html } from '@lit-labs/ssr';
import { collectResult } from<EMAIL_ADDRESS>
const template = ({ title, lang }) => html`
  <!DOCTYPE html>

      <title>${title}</title>

${title}

`;

const ssrResult = render(template({ title: 'My Website', lang: 'en'}));
const ssrContent = await collectResult(ssrResult);

console.log({ ssrContent });

doing this will result in an invalid locations error
file:///Users/owenbuckley/Workspace/github/lit-v3-ssr-demo/node_modules/@lit-labs/ssr/lib/render-value.js:605
        throw new Error(errorMsg);
              ^
Error:
    Unexpected final partIndex: 2 !== 3 while processing the following template:

  <!DOCTYPE html>

      <title>${...}</title>

${...}

    This could be because you're attempting to render an expression in an invalid location. See
    https://lit.dev/docs/templates/expressions/#invalid-locations for more information about invalid expression
    locations.

Reproduction
I have a repro repo setup here you can check out
https://github.com/thescientist13/lit-v3-ssr-demo/tree/master#document-
Just clone, run npm ci and then run npm run demo:document.  The relevant code is in document.js
Workaround
not really a work around, but It should be noted if I remove the lang=${...} from the template, the error goes away.
{
  ssrContent: '\n' +
    '  <!DOCTYPE html>\n' +
    '  \n' +
    '    \n' +
    '      \n' +
    '      <title>My Website</title>\n' +
    '    \n' +
    '    \n' +
    '
My Website
\n' +
    '    \n' +
    '  \n'
}

Not sure if I am doing something wrong?  In the repro repo I conducted another experiment to SSR a greeting component and that all seemed to go fine, so at least I'm doing something right somewhere 😅
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
@lit-labs/ssr: ^3.2.0,  lit: ^3.1.0
Browser/OS/Node environment
macOS: 14.0
Node: 18.12.1
npm: 8.19.2

You are not doing something wrong, this is a real bug. Thank you for the report!
The bug is that  currently doesn't get handled correctly, and the lang attribute is skipped. This then results in a part mismatch error being thrown.
It'll be fixed with https://github.com/lit/lit/issues/4417


Show transferred IOTX amount when invoke contract

https://iotexscan.io/action/53ec6374784782cc5e5cafac4aedaece76f50d09db64a91ece51a64456ff1c2c
"Tokens Transferred:" is NULL but in fact, it is not, i.e., amount: 0.000000000000000123 IOTX
ioctl action hash 53ec6374784782cc5e5cafac4aedaece76f50d09db64a91ece51a64456ff1c2c
version: 1  nonce: 30  gasLimit: 1000000  gasPrice: 0.000001 IOTX
senderAddress: io17awtxw3cm4hhku50nshw9250dfyfj576ykumrm
execution: <
  contract: io1jjwlujpk7wztptwdjvun268ccsadsd7dtl2alq
  amount: 0.000000000000000123 IOTX
  data: 7fd283460000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000002800000000220000001000000000000000000000002000000001000000000000000000000020000000000000000000000000000000000000000000000000000000
>
senderPubKey: 045ef85521e2c4e3feac5b063d06a2caf2412458ebaa3636aef1ed5e9ba198926781fdac671a78543ac46b43f26a07a751e2a7c7bff26238dda9609d594f4edb2c
signature: 0cceb70f3319409319c8b77ec89454b5f823b21d05ab6bf62ab17a7f01754fd53e012682807942269716f49657955329775a7beb0babf74311dc5cda27366d4a00
timeStamp:<PHONE_NUMBER>
blkHash: 549281f762566314eef4342985671b3bf198669055c10d41e11c7b1897cfe02d
actHash: 53ec6374784782cc5e5cafac4aedaece76f50d09db64a91ece51a64456ff1c2c

#This action has been written on blockchain

status: 106 (Failure : Execution reverted)
actHash: 53ec6374784782cc5e5cafac4aedaece76f50d09db64a91ece51a64456ff1c2c
blkHeight: 7599928
gasConsumed: 23312
logs:<
>

i think it is OK not to show, because the tx is reverted, there is actually NO token transferred
@hunglmtb please verify the front-end display only displays amount for successful contract tx

it's using query list of token transfer from analytic
query {
    action {
      byHash(actHash: "${hash}") {
        evmTransfers {
          from
          to
          quantity
        }
      }
    }
  }

this Pr trying to decode the log for tokens transfer instead of fetching from analytic https://github.com/iotexproject/iotex-explorer/pull/1680
in the hash above, the log is empty so the PR will display empty for tokens transfer


Update "try Cognitive Services for free" link

Closing at request of Giampaolo Battaglia as this repo no longer belongs to Cognitive Services.


Add pipefail to test script

Actually it would be better not to fix the REST resource at first, to check that the build failure is reported correctly.

Actually it would be better not to fix the REST resource at first, to check that the build failure is reported correctly.

Yeah realized that right after I pushed my commit... I'll see what this does and then comment out and try again


[Snackbar] Shouldn't be light in dark mode

[X] I have followed (at least) the PR section of the contributing guide.

https://deploy-preview-24704--material-ui.netlify.app/components/snackbars/
Closes  #24438

@Renfrew This change makes the snackbar light in light mode.

@Renfrew This change makes the snackbar light in light mode.

@mbrookes Should I keep it dark?

@mbrookes Should I keep it dark?

Will push soon

Will push soon

It looks like I was wrong. It's fine to have the snackbar light in dark mode: https://material.io/design/color/dark-theme.html#custom-application

Thanks for looking into it

It looks like I was wrong. It's fine to have the snackbar light in dark mode: https://material.io/design/color/dark-theme.html#custom-application

Thanks for looking into it


Docs/fix attrsets

Description of changes
[x] Add some more type annotations to lib/attrsets.nix
[x] Fix some errors in the existing ones.
[x] Minor enhancements for comprehensiveness.
some background:
noogle.dev
Recently started noogle.dev - A search engine for functions within nix. :star:
-> Site here
-> Github here
Currently available on  noogle.dev

everything from lib folder
All nix builtins

Its currently under development and i would like to Index all nixpkgs functions.
This involves typing all functions, starting with the most important ones. (like libs, trivial-builders, builtins, etc)
I will maintain those types inside my fork and sync them with the official nixpkgs on regular basis.
I am happy if you share and use this site. :heart:
Things done

[x] Parsed with nixdoc
[x] Double checked every type

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md

@infinisil Just because i dont know, is there some rfc/standard; describing the convention for the typing system ?
The current way seems to be somehow related to the haskell annotations.

@hsjobeki There is not, but yes it's a conventional mix of Haskell and the module system types (e.g. there's lib.types.attrsOf)

Not directly related to this PR, but:
Maybe we could make the lib.types.* consistent with that "conventional mix; type comments"
currently nixosOptionsDoc prints the description field. (e.g. "null or (list of string)" ) which is inconsistent with the type comments. (for nixos module system - mkOption)
I don't know if anyone depends on the output of nixosOptionsDoc type field. But I'd like to have consistent output in all places that can be used to generate e.g. docs / can be used from additional Tools. (like noogle)

I agree that would be nice. Not sure how well that will work though, because the module system types (lib.types) are not just types but also merging of values. So e.g. types.str and types.lines accept the same values, but they get merged in a different way. Also keep in mind that the module system doesn't really use functions, which is part of the point of it. This is in contrast to the lib functions, which are pretty much entirely functions. So the types would look fairly differently even if consistent.
Ideally of course we'd be using something like the module system for the lib functions as well, and the rest of Nix too, but maybe that's a bit ambitious for now :stuck_out_tongue:.

Can you squash the changes a bit? 1 commit might be good. The convention is also to rebase instead of merging master

Can you squash the changes a bit? 1 commit might be good. The convention is also to rebase instead of merging master

Rebase on current master, was a bad idea because my fork was about 2 months old, containing already all the types you recently added here ;). So i had conflicts in about 30 of 3k commits ;).
With some git rework should be clean now.


feat: migrate the api to rust to get faster access

[ ] use actix

what to use for graphql queries......😕


A couple minor priority elevation bug fixes in TaskScheduler

Fix two issue:

If a task’s priority got elevated, we would emit the Elevating priority log message repeatedly until the elevated priority is propagated to the underlying task via withTaskPriorityChangedHandler
Explicitly set the priority of QueuedTask, which ensures that we create the detached resultTask inside of it with that priority. I’m not sure if this was an actual issue but seems like a good cleanup regardless.

@swift-ci Please test


Provide CosmosDB native repository

Is your feature request related to a problem? Please describe.
In our project we're using Comsos DB as our backend database and we are using it with both single and hierarchical/hashed partition keys. The current implementation using EF to access the Cosmos DB is limited to partition keys that are the same as the ID and the EF Core team does not yet support hierarchical/hashed partition keys.
This means that we can't use the provided TableController because to get or delete an item we need the client to send the partition key in order to do the lookup. So, long story short, we had to roll our own controllers. This works fine for successful http requests, but if we want to return a PreconditionFailedException then the client will never get the payload of the exception because the DatasyncExceptionsAttribute is internal.
Describe the solution you'd like
For now, I think the simplest solution would be to change all of the attributes found on the default TableController to be changed from internal to public:

DatasyncExceptionsAttribute
DatasyncProtocolVersionFilterAttribute
AzureMobileBackwardsCompatibilityFilter

As well as the following helpers that are used in the TableController:

HttpRequestExtensions
ITableDataExtensions

Describe alternatives you've considered
Another option would be to make a Cosmos DB specific library that would allow the client to pass in the required partition key information, but I believe these classes would still need to be made public to do this.
Additional context
I've created a PR for this: #786

Thanks for the quick response, I would love some input on this. Note that we have implemented our own repositories, but as you will see below, they have a similar issue as the TableController.
The issue is that in Cosmos DB, both the ID and partition key are required for unique identification of a document. Your current ReadAsync() and DeleteAsync() methods in TableController and IRepository only accept the ID. This is problematic, especially when using hierarchical/hashed partition key, as you may need additional properties to perform reads/deletes.

Using a plain query to select by only the ID incurs extra costs. A point read operation with both ID and partition key costs 1 Request Unit (RU), but a query based only on the ID will have variable cost depending on the number of partitions and object size.

Funny, I was just thinking about that as an option.

Let's re-title this issue (and update the description) to "Provide CosmosDB native repository"

I'll see how things go with using a compound id with our implementation and maybe I'll be able to create a comsos sdk project if I'm successful. Thanks 😊

@adrianhall FYI I've started this on a branch on my repo here: https://github.com/Azure/azure-mobile-apps/compare/main...blackeyedyl:azure-mobile-apps:cosmos-repository
The easy bits are in, next is to figure out how to handle the partition keys (I've added // TODO everywhere we need a partion key.
I've reused the EtagEntityTableData from the EFCore implementation. Would probably be good to re-use that instead of copy pasting but wasn't sure where best to put that along with the tests for it.

I would suggest a new project (let's say Microsoft.AspNetCore.Cosmos) with a CosmosRepository and a CosmosTableData - just like the LiteDB and EFCore versions.  This way, the repo stands on its own and doesn't require entity framework as a dependency.

Looks like you have opted for CosmosTableData - which is a good plan.

@adrianhall looks like Cosmos SDK doesn't support LongCount():

Microsoft.Azure.Cosmos.Linq.DocumentQueryException: Method 'LongCount' is not supported.

https://github.com/Azure/azure-cosmos-dotnet-v3/issues/1505
https://github.com/Azure/azure-cosmos-dotnet-v3/issues/738

Looks like you have opted for CosmosTableData - which is a good plan.

Just building based on the other implementations. My only concern with this approach is that the model must inherit from CosmosTableData which works if you have a client model and a server model. I would like to support a model that's shared between the client and server. Thoughts?

The short version is "no - don't do that".  There is generally private data that is used in determining if the user should have access to the data on the server side that isn't (and can't be) present on the client side.  There may be other restrictions as well - data types are not necessarily common, for instance.

For the LongCount() problem, I was thinking of adding a CountAsync(queryable) to the repository anyhow - this might be the appropriate time to do that functionality.

Ref: PR #788 - once that is merged, we won't be using .LongCount() any more.

Running into another OData issue which seems a bit trickier to fix. When I run the sample app I added in my branch and try to $select a column I get the following:

Newtonsoft.Json.JsonSerializationException: Self referencing loop detected for property 'declaringType' with type 'Microsoft.OData.Edm.EdmEntityType'. Path 'typedProperty.schemaElements[0].declaredKey[0]'.

This seems to be a "known" issue with OData and Cosmos, but it's unclear on how to fix it from my preliminary search:
Some folks say that adding AddODataNewtonsoftJson() fixes it, but for me it has no effect:
https://github.com/JamesNK/Newtonsoft.Json/issues/2649#issuecomment-1169616961
When I tried to add ReferenceLoopHandling = ReferenceLoopHandling.Ignore I end up with an infinite loop similar to the issue reported here:
https://github.com/OData/AspNetCoreOData/issues/87#issuecomment-960377856

I'm surprised the EF Core driver doesn't have this problem.  I'll dig a little bit this weekend (now I've got 6.0.4 out)

Hi @adrianhall, have you had any time to think on that serialization issue?
The cosmos server repository is making good progress, and the code in my branch is functioning well. However, the datasync client code to check for a valid ID is causing some challenges with the "constructed key" concept, here is the relevant code:
https://github.com/Azure/azure-mobile-apps/blob/940cfa18de2e0ec270b8828e95938f9f022c0f1c/sdk/dotnet/src/Microsoft.Datasync.Client/Utils/Arguments.cs#L25
https://github.com/Azure/azure-mobile-apps/blob/940cfa18de2e0ec270b8828e95938f9f022c0f1c/sdk/dotnet/src/Microsoft.Datasync.Client/Utils/Arguments.cs#L121
Partition keys can be any non-null string up to 100 characters in length, and there can be up to three partition keys. Would it make sense to allow a client option to override the default ID regex?

Your ID must conform to a path segment definition in RFC 2396 and fit into the ID field of the table.   It's currently between 1 and 126 characters.  Is 126 not big enough?  I get that partition keys CAN be that length, but can we put some reasonable restrictions on them?

... and, no, I've not had time to download your code and prod yet.  I'm setting aside Friday for this task.

Your ID must conform to a path segment definition in RFC 2396 and fit into the ID field of the table. It's currently between 1 and 126 characters. Is 126 not big enough? I get that partition keys CAN be that length, but can we put some reasonable restrictions on them?

The 126 length is likely fine, its more about the allowed characters. I can work around the specific issue I'm encountering.

I'm happy to add additional characters, as long as they aren't "wildcard" characters.  Preferably, only characters that don't need to be encoded on the URL (hence the RFC 2396).  If they have to be URL encoded, that can cause other issues.
Want to put in a PR with your preferred character set?

Thanks @adrianhall, but the specific character would need to be encoded, so no worries. The restrictions makes sense.
Now I'm struggling with where and when to do the translation of the id so that things work with the SQLite implementation of OfflineTable which uses JObjects. I'm not sure if I'm running into a technical limitation or I'm just going about things incorrectly.
Quoting the original idea:

The ID in the DTO is up to you - it's an opaque string. There is no reason you can't construct an ID in the DTO from the ID+PartitionKey in the Cosmos table.
In your repository, have an ID translator (both ways) and use it throughout as necessary.

Given the following TodoItems partitioned by the UserId property:

id /UserId
1 /Bilbo
2 /Bilbo
1 /Samwise
3 /Bilbo
2 /Samwise

(Cosmos DB allows ID re-use on separate partitions in reality we are generally using guids)

Since the OfflineTable seems to save data from the get API calls to the SQLite database from the JObject so it's up to the API to return a constructed ID for the TodoItems (1:Bilbo, 2:Samwise , etc), and likewise the API expects any data objects sent to the server to have an ID set to the constructed ID.
I'm unsure on how to structure the server DTO objects so that Repository.Query() serializes the objects with the constructed ID and also use those same objects within the repository to save the ID to the database without the ":UserId" in the ID.
I hope my explanation is clear. I tried to avoid making it too lengthy but could really use some direction here.
FYI I've updated the new cosmos sample in my branch to have a container partitioned on the UserId to help with this discussion:
https://github.com/blackeyedyl/azure-mobile-apps/tree/779b15b4515e2ad7bcbf6150a2c2a46e16186cd7/samples/Samples.Cosmos.SDK

I downloaded the branch to see what was going on, but there were too many compile time errors for the sample.  I'll take a stronger look tomorrow based on just the SDK and unit tests.

Compile time errors? That's embarrassing! I'll double check the branch this evening.
FYI I'm using VS 2022 on Windows

Looks like I may have been missing a few commits, I cloned and compiled the sample and SDK on my Mac and it seems to be running for me.

I have found a "solution", but I don't know if I am happy with it as it has a house of cards feel to it. Because Cosmos and the Controller are using the same model object I added some extra code to the CosmosTableData object to allow the ID to be translated and return the constructed ID when the AsQueryable() is called. This works great, except when creating and replacing the object I need to pass in an entity with a non-constructed ID. For now I have worked around this by adding a trigger to my container that fixes the ID before the record is upserted - which is the house of cards part.
I've checked in the sample, updates and tests but like I said this feels like a workaround rather than a solution because everything needs to be setup just right for it to work.
Note: I also added a .http file to the sample to help with testing.

I removed my previous comment because the trigger solution wasn't viable. I think I have come up with something that might work:

CosmosTableData object can be extended to return a constructed ID, which is needed so that calls to AsQueryable() returns the constructed ID.
Parse the ID and PartitionKey from the contructed ID when calling ReadAsync()
When updating the database with ReplaceAsync() and CreateAsync() I'm using the Cosmos serializer to convert the passed in entity to a JObject update it with the database ID. This JObject is then used to update the database.

More tests and testing is needed this week, but it's feeling like this could work if we always want to return a constructed ID.

Hi @adrianhall I think the native cosmos library is at a point where feedback would be appreciated. We are using it in-house, and it seems to be working quite well. We are using both the remote and offline tables on the client side, and a mix of single and hierarchical partition keys on the Cosmos DB side.
The main challenges were:

OData select is not supported which I believe this can be a known limitation - thoughts?
Handling of the constructed IDs: the DTO model object needed to include code to construct and deconstruct the IDs to work with the standard CRUD operations as well as the AsQueryable() operation. I also needed to edit the cosmos JSON stream to ensure the deconstructed ID was saved to the cosmos database.
Handling of dates: cosmos doesn't have a date field, so I had to ensure that the dates/offsets were saved to the cosmos containers with the correct format. I add a default cosmos serializer class to ensure dates were saved to the database in ISO 8601 format instead of the interchange format used by the sync library.

The only "TODO" tasks I have remaining is to add better handling of double and bool partition key values. If you believe that this new project is ready to be merged into your repository, I'll start working on this if it's deemed important.
My 'cosmos-repository' branch can be found here: 'https://github.com/blackeyedyl/azure-mobile-apps/tree/cosmos-repository' - I can create a PR if that would be preferred.
The last time you checked out the project, you mentioned some compile errors. Hopefully, those have been resolved, but if not, please let me know the specific errors so that I can investigate. It's possible that I might have used some newer C# language features that need adjustment.

I think OData select is a big deal.  It breaks the promise that the client doesn’t need to know how the server installed.  The rest of it is fairly straight forward and looks good.  I’ll talk to the Cosmos team to see what we can do about the select problem next week.

I tried looking into the EF Core implementation of CosmosDB, and at a glance they might be handling the "select" operation on the client-side. Would it be a good idea to enable the repository to extend when client-side evaluation should take place by adding a repository call as part of the IsClientSideEvaluationException() logic. Alternatively, the repository could inform the table controller about which OData capabilities should be handled client-side.
/// <summary>
/// Determines if a particular exception indicates a client-side evaluation is required.
/// </summary>
/// <param name="ex">The exception that was thrown by the service-side evaluator</param>
/// <returns>true if a client-side evaluation is required.</returns>
[NonAction]
internal static bool IsClientSideEvaluationException(Exception ex)
    => ex != null && (ex is InvalidOperationException || ex is NotSupportedException);

Based on the comments in the Query() method in the TableController this is needed for EF Core for similar reasons.
Below is the full exception:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> Newtonsoft.Json.JsonSerializationException: Self referencing loop detected for property 'declaringType' with type 'Microsoft.OData.Edm.EdmEntityType'. Path 'typedProperty.schemaElements[0].declaredKey[0]'.
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.CheckForCircularReference(JsonWriter writer, Object value, JsonProperty property, JsonContract contract, JsonContainerContract containerContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.CalculatePropertyValues(JsonWriter writer, Object value, JsonContainerContract contract, JsonProperty member, JsonProperty property, JsonContract& memberContract, Object& memberValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeList(JsonWriter writer, IEnumerable values, JsonArrayContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeList(JsonWriter writer, IEnumerable values, JsonArrayContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.Serialize(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonSerializer.SerializeInternal(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonConvert.SerializeObjectInternal(Object value, Type type, JsonSerializer jsonSerializer)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitConstant(ConstantExpression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitNonSubqueryScalarExpression(Expression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitNonSubqueryScalarExpression(Expression expression, ReadOnlyCollection`1 parameters, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitScalarExpression(Expression expression, ReadOnlyCollection`1 parameters, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitScalarExpression(Expression expression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitMemberAccess(MemberExpression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitNonSubqueryScalarExpression(Expression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitNonSubqueryScalarExpression(Expression expression, ReadOnlyCollection`1 parameters, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitScalarExpression(Expression expression, ReadOnlyCollection`1 parameters, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitScalarExpression(Expression expression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitMemberAssignment(MemberAssignment inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitBinding(MemberBinding binding, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitBindingList(ReadOnlyCollection`1 inputExpressionList, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitMemberInit(MemberInitExpression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitNonSubqueryScalarExpression(Expression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitNonSubqueryScalarExpression(Expression expression, ReadOnlyCollection`1 parameters, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitScalarExpression(Expression expression, ReadOnlyCollection`1 parameters, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitScalarExpression(LambdaExpression lambda, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitSelect(ReadOnlyCollection`1 arguments, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitMethodCall(MethodCallExpression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.Translate(Expression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.VisitMethodCall(MethodCallExpression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.Translate(Expression inputExpression, TranslationContext context)
   at Microsoft.Azure.Cosmos.Linq.ExpressionToSql.TranslateQuery(Expression inputExpression, IDictionary`2 parameters, CosmosLinqSerializerOptions linqSerializerOptions)
   at Microsoft.Azure.Cosmos.Linq.SqlTranslator.TranslateQuery(Expression inputExpression, CosmosLinqSerializerOptions linqSerializerOptions, IDictionary`2 parameters)
   at Microsoft.Azure.Cosmos.Linq.DocumentQueryEvaluator.HandleMethodCallExpression(MethodCallExpression expression, IDictionary`2 parameters, CosmosLinqSerializerOptions linqSerializerOptions)
   at Microsoft.Azure.Cosmos.Linq.DocumentQueryEvaluator.Evaluate(Expression expression, CosmosLinqSerializerOptions linqSerializerOptions, IDictionary`2 parameters)
   at Microsoft.Azure.Cosmos.Linq.CosmosLinqQuery`1.CreateFeedIterator(Boolean isContinuationExpected)
   at Microsoft.Azure.Cosmos.Linq.CosmosLinqQuery`1.GetEnumerator()+MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at Microsoft.AspNetCore.OData.Query.Container.TruncatedCollection`1..ctor(IQueryable`1 source, Int32 pageSize, Boolean parameterize)
   at Microsoft.AspNetCore.OData.Query.ODataQueryOptions.LimitResults[T](IQueryable`1 queryable, Int32 limit, Boolean parameterize, Boolean& resultsLimited)
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Datasync.TableController`1.CatchClientSideEvaluationException(Exception ex, String reason, Action clientSideEvaluator) in C:\Users\Dylan.Mills\source\repos\datasync\sdk\dotnet\src\Microsoft.AspNetCore.Datasync\Tables\TableController.cs:line 144
   at Microsoft.AspNetCore.Datasync.TableController`1.QueryAsync(CancellationToken token) in C:\Users\Dylan.Mills\source\repos\datasync\sdk\dotnet\src\Microsoft.AspNetCore.Datasync\Tables\TableController.cs:line 394
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(ActionContext actionContext, IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|26_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ExceptionContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeNextResourceFilter()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.InvokeCore(HttpContext context)
   at NSwag.AspNetCore.Middlewares.SwaggerUiIndexMiddleware.Invoke(HttpContext context)
   at NSwag.AspNetCore.Middlewares.RedirectToIndexMiddleware.Invoke(HttpContext context)
   at NSwag.AspNetCore.Middlewares.OpenApiDocumentMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

Understood.  I'm going to be working with the Cosmos SDK team on this topic.

I'm quickly becoming convinced that a generalized cosmos client is not possible because of the varying partition key requirements.  Whatever we do, we're not going to be able to derive the partition key from the ID in all cases.  If we do, we then are putting constraints on the ID beyond "it's a string", which breaks the "the client doesn't know what the server has implemented" thing.
We can certainly create, delete, update and use one of the fields within the object as the partition key(s), which then generates the ID.  The problem is that the ID is not generated by the server in the case of offline.  I'm not currently seeing a way around this as that ID is used as a key in the offline database.
Will need to do some more thinking about this, but it's non-obvious at this point in time.

I had a suspicion that this might be the outcome here and I agree with what you've said. The datasync library is designed to work with a single key to define a unit of data within a "table." Cosmos DB generally requires at least two keys per data unit—except in the specific case of using /id as the partition key. The single-key-per-unit approach aligns well with relational databases, which likely comprises the majority of the user base for this library.
That said, Cosmos DB could be an excellent candidate for a fork of this library due to its built-in Version (_etag) and UpdatedAt (ts) for every document. With an updated API and using composite keys on the client SQLite database, a Cosmos-compatible version could be implemented with either EF Core or Cosmos SDK repositories.
For our purposes on this specific project, the v6 datasync library has enough benefits that we've decided to continue using it with the understanding that the cosmos native repository isn't going to be general enough for inclusion in the official library. Going forward I'll keep an eye on the v8 implementation to see if we want to go that direction: combining the offline/remote tables will be great for us to simplify some of our code, multi-item push will also be great.


Wrong permissions on 0.7.3 gem

Hi,
The permissions on the 0.7.3 release are wrong:
sandbox:/root@[15:43] # ls -al /usr/local/lib/ruby/gems/2.0/gems/http-0.7.1/lib/
total 22
drwxr-xr-x  3 root  wheel    4 Feb 12 13:25 .
drwxr-xr-x  5 root  wheel   19 Feb 12 13:25 ..
drwxr-xr-x  6 root  wheel   17 Feb 12 13:25 http
-rw-r--r--  1 root  wheel  448 Feb 12 13:25 http.rb
sandbox:/root@[15:43] # ls -al /usr/local/lib/ruby/gems/2.0/gems/http-0.7.3/lib/
total 22
drwxr-xr-x  3 root  wheel    4 Mar 31 15:43 .
drwxr-xr-x  5 root  wheel   19 Mar 31 15:43 ..
drwxr-xr-x  6 root  wheel   17 Mar 31 15:43 http
-rw-r-----  1 root  wheel  448 Mar 31 15:43 http.rb

When requiring 'http' as an user, RuyGems raises "LoadError: cannot load such file -- http" because it cannot load the file due to permissions.
Reproduced on Debian Wheezy and FreeBSD 10.0-RELEASE, and Ruby 2.0 & Ruby 2.1

Indeed. @tarcieri I'll re-release gem.

@ixti Any idea how it got into that state? It appears that this is not just http.rb but all files in the gem.

@ixti What exactly did you change? I don’t see any permissions changes in the 0-7-stable branch. What can we do to ensure this doesn’t happen again?

@eraserewind Thanks for the report, released gem with fixed perms as 0.7.4.

@sferik I have just repacked (re-released) gem. Seems like something on @tarcieri's end. gem build on his machine somehow produced gzipped tarball with wrong permissions.

I'm guessing it probably had to do with the default umask of the laptop I did the release from

@tarcieri most likely.

Thanks guys! :smile_cat:


Translations are not rendered during SSR

I don't see any translations/locales in SSR output. Texts appearing only on frontend. Could you please give me any ideas why it can happened?

As far as I know, everything works well in terms of SSR within our examples have you tried to use some of them in your project? I think there might be an issue with your implementation..

Actually, I just copy relevant parts of multi-page example, eg. cookie usage, reading the header etc, but replaced the loading of local files with translations, with the use of my backend. I just start to test it with sveltekit and looks like I don't have much self-written code to face with implementation issue. I've +layout.server with such content:
import { locales, loadTranslations } from '$lib/services/i18n';
import { getLocale } from '$lib/services/api';

export async function load({ url, cookies, request, fetch }) {
	const { pathname } = url;

	// Try to get the locale from cookie or user preferred locale
	const localeCode =
		cookies.get('locale') || `${`${request.headers.get('accept-language')}`.match(/[^(,|;)]*/)}`;

	const supportedLocales = locales.get();

	const locale = await getLocale(
		fetch,
		supportedLocales.includes(localeCode) ? '/' + localeCode : ''
	);

	await loadTranslations(locale.locale, pathname);

	return {
		locale
	};
}

And +layout.js with this:
import { setLocale, setRoute } from '$lib/services/i18n';

export async function load({ url, data }) {
	const { pathname } = url;
	const { locale } = data;

	await setRoute(pathname);
	await setLocale(locale.locale);

	return {
		locale
	};
}

I SSR output I see all necessary markup (html elements, forms, button etc) except texts. All places where I expect text replaced by fallback values from sveltekit-i18n config, like:
const config = {
	fallbackValue: '-',
	loaders: [...]
};

-

What am I did wrong?

The issue solved. Looks like, I had the problems with universal fetch requests on server-side. Fetch was working only on client, thats why text appears only on frontend side


Scaffold cloning mechanism not respecting git ssh configuration

My authentication with GitHub is done with SSH keys (rather than https://) and I use a Yubikey to provide my SSH keys.  I assure you that my git commands work properly. 😉
To ensure I use git+ssh rather than https:// for cloning things, I have the following in my ~/.gitconfig:
[url "git@github.com:"]
  insteadOf = https://github.com/

So, proving my git works:
$ git clone https://github.com/apollographql/router.git
Cloning into 'router'...
remote: Enumerating objects: 20071, done.
remote: Counting objects: 100% (110/110), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 20071 (delta 66), reused 61 (delta 38), pack-reused 19961
Receiving objects: 100% (20071/20071), 7.17 MiB | 6.66 MiB/s, done.
Resolving deltas: 100% (14418/14418), done.

However, when I try this with cargo-scaffold using the https:// URL, I receive:
$ cargo-scaffold scaffold https://github.com/apollographql/router.git -r apollo-router-scaffold/templates/base
🔄 Cloning repository…
Error: authentication required but no callback set; class=Ssh (23); code=Auth (-16)

... and with the git+ssh approach:
$ cargo-scaffold scaffold git@github.com:apollographql/router.git -r apollo-router-scaffold/templates/base
🔄 Cloning repository…
Error: Failed to authenticate SSH session: Unable to extract public key from private key file: Unable to open private key file; class=Ssh (23)

Ultimately, I think this comes down to the same challenge that cargo ran into by trying to use an underlying git library that wasn't a full implementation of the git CLI's abilities — for example, the CARGO_NET_GIT_FETCH_WITH_CLI env variable and its corresponding setting.  (For what it's worth, I tried using that env variable, but it didn't help, though I'm not surprised since that's cargo-specific behavior).
Those limitations are explained a bit in https://github.com/rust-lang/cargo/blob/9ded34a558a900563b0acf3730e223c649cf859d/src/cargo/sources/git/utils.rs#L816-L905 where you can see how they work around it.

This could maybe partially be fixed by #40, which adds more authentication mechanisms, including using the ssh agent and more default keys in addition to ~/.ssh/id_rsa.
I'm not sure about the insteadOf. That sounds like libgit2 simply doesn't implement it, so using auth-git2 would not solve that.


NFT Auction Smart Contract

Allows users to auction NFTs for any Price symbol.

Fee: 1 BEE
Max Allowed NFTs at one auction: 50

An Auction can run up to 30 days, and attempts to settle after 24 hours of lead bid. To take the lead a bid must be 5% or more from the previous bid and it resets the 24 hour timer. Bids can be cancelled anytime except 5 minutes before settlement. At any given time owner can cancel the auction or settle it with specific or the current lead bid. Bids can be updated with larger quantity at any time. owner may set a minimum bid and a final price which settles the auction immediately if hit. After settlement, the winner gets NFTs and seller gets his bid. All other bids are returned.

During testing, reazuliqbal found the following points of concern.  Please resolve each of these:

Seller can bid on their own auction
Cancelled auctions are not removed from the database (also no indication that they are canceled) but NFTs are sent back to the seller
Cancelled auctions can receive bids
After cancellation its possible to have multiple auctions for the same NFTs, so very hard to distinguish which is cancelled which are not.
Its possible to settle a cancelled auction if someone bids on it, the contract sends the NFT to the bidder even tho it does not have it.

Also, Aggroed has indicated a preference to have the auction contract include market fees similar to the NFT market contract.  This is especially important for NFT Showroom, and in particular it should obey the officialMarket, agentCut, and minFee that are configured for the NFT in question.  See documentation here for details: https://github.com/hive-engine/steemsmartcontracts-wiki/blob/master/NFT-Market-Contract.md#configuring-the-market

Update:

Sellers now can not bid on their own auction
Canceled auctions now get deleted also a fix in test file which now confirms it
Added a fee mechanism similar to nftmarket contract
nft issuers can set marketParams that define official market account, agent fee cut and minimum fee
separate test unit for fee mechanism, market params etc


GNOME updates 2023-04-24 (staging)

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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 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.

@ofborg build libnma

Note that the Budgie crash isn't related to this Vala update, I triggered that crash with Vala 0.56.5/6 yesterday and the experience is painful :upside_down_face:

geary build regressed now: https://hydra.nixos.org/build/217892787 (same on both *-linux)  I haven't tried finding what triggered it, but I'd suspect the vala update.  (Not so easy to verify, at it needs a webkitgtk rebuild.)


chore: remove email from test

I'm recieving notification emails that are sent in local enviornment to my email. You might want to disregard this PR if you have some other place you want these to end up.
But should work to send the tests to the Group email that you can all have access to and inspect.

@vehecap


[SPARK-18932][SQL] Support partial aggregation for collect_set/collect_list

What changes were proposed in this pull request?
Currently collect_set/collect_list aggregation expression don't support partial aggregation. This patch is to enable partial aggregation for them.
How was this patch tested?
Jenkins tests.
Please review http://spark.apache.org/contributing.html before opening a pull request.

Test build #70459 has started for PR 16371 at commit 6e8aa82.

Test build #70464 has started for PR 16371 at commit 68d1e98.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70464/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70459/
Test FAILed.

Merged build finished. Test FAILed.

Test build #70467 has started for PR 16371 at commit 6677beb.

Why would we even want to support partial aggregation for collect_list?

@marmbrus I see that you filed the ticket. We can make this work with partial aggregation, but we shouldn't run them this way. Maybe it's time to define something as partial aggregateable vs should be partially aggregated.

Test build #70467 has finished for PR 16371 at commit 6677beb.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70467/
Test FAILed.

Merged build finished. Test FAILed.

If we can have some definition for something should be partially aggregated and something not, that would be great.

Just for reference. Hive's collect_list and collect_set seems supporting partial aggregation. Of course we don't necessarily follow Hive's.
https://github.com/apache/hive/blob/ff67cdda1c538dc65087878eeba3e165cf3230f4/ql/src/java/org/apache/hadoop/hive/ql/udf/generic/GenericUDAFMkCollectionEvaluator.java

Is there a problem with running partial aggregation for collect_list?  Even if there isn't an improvement, at least now you don't disable partial aggregation for other functions that are also being computed.

Test build #70504 has started for PR 16371 at commit 559db5b.

Test build #70504 has finished for PR 16371 at commit 559db5b.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class DummpAgg(

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70504/
Test PASSed.

Merged build finished. Test PASSed.

@viirya I left a few comments on the PR. Lets wait for some consensus before pushing ahead.

sounds good.

@hvanhovell Got it. Thanks for review.

I think we should implement collect with TypedImperativeAggregate and remove the supportsPartual flag, @viirya do you have time to work on it?

@cloud-fan I already did this in current PR. I am waiting for some consensus so I can push ahead to address the review comments from @hvanhovell.

I think we should support partial aggregation for collect, in the future we can define an interface to declare "should partial aggregate", so that a single collect function won't cause a 2-phase aggregation.
I think they are orthogonal and we can go ahead.

+1 I think we can move forward.

@cloud-fan @marmbrus ok. I will first address @hvanhovell's comments.

Test build #70707 has started for PR 16371 at commit f60e824.

Test build #70709 has started for PR 16371 at commit 965a4a9.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70709/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70707/
Test FAILed.

Merged build finished. Test FAILed.

retest this please.

Test build #70713 has started for PR 16371 at commit 965a4a9.

Test build #70733 has started for PR 16371 at commit c2f3841.

Test build #70733 has finished for PR 16371 at commit c2f3841.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70733/
Test PASSed.

Test build #70756 has started for PR 16371 at commit 5c6b02a.

Test build #70756 has finished for PR 16371 at commit 5c6b02a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70756/
Test PASSed.

Test build #70801 has started for PR 16371 at commit 15a10ee.

LGTM

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70801/
Test FAILed.

Merged build finished. Test FAILed.

retest this please.

Test build #70810 has started for PR 16371 at commit 15a10ee.

LGTM

Test build #70810 has finished for PR 16371 at commit 15a10ee.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70810/
Test PASSed.

thanks, merging to master!

Thank you @cloud-fan @hvanhovell @rxin @marmbrus


Refactor getting popular repositories API to return detail info

Currently the repositories returned by API only contain name and pull count. UI needs more properties such as tags count project ID. Is it right @steven-zou ?

Finished by #1563 .


Remove SESSION_MANAGEMENT_2024Q1 feature toggle in 1.4

Tech Debt
SESSION_MANAGEMENT_2024Q1 is enabled by default in 1.3 and should be removed in 1.4.
AB#2577651

#611 completes the necessary work.


Upgrade to .NET 8

Update the sample to target .NET 8

@IEvangelist Could you help update frontend to net8? I'm not quite familiar with blazor

Marking issue as complete.


discubation, adder

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 30
deps=[a,d]

/trunk merge


[DOCS] Add Issues Heading in CONTRIBUTING.md

Description
In CONTRIBUTING.md, contributors need to know the right way to add an issue. For example, if a contributor needs to report a bug then they should see the right way to report it in the CONTRIBUTING.md.
Screenshots
The issues heading section should look like this

The change shouldn't look exactly like this :)
Additional information
No response

@clairecharles Go for it


fix(su): always show email to organizers

:tada: This PR is included in version 1.32.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fix IE getBoundingClientRect bug and upgrade packages

Not sure what happened with the examples bundle - should that be compiled with a prod flag?

Coverage increased (+2.4%) to 90.0% when pulling 2a20bf83055342a2d426016a13569e06a5e55fcf on wub:master into dda5f6a2f0b0b3993616a1f98c27a500e5fcef3a on jasonslyvia:master.

Coverage increased (+2.4%) to 90.0% when pulling d554459c2b36c0f3eaf9a04fc77b28d0c93e362a on wub:master into dda5f6a2f0b0b3993616a1f98c27a500e5fcef3a on jasonslyvia:master.

Coverage increased (+2.4%) to 90.0% when pulling d554459c2b36c0f3eaf9a04fc77b28d0c93e362a on wub:master into dda5f6a2f0b0b3993616a1f98c27a500e5fcef3a on jasonslyvia:master.

Oh, please just left out all the compiled code, so we can have a better diff.

Coverage increased (+2.4%) to 90.0% when pulling 07f9aa164dc63c8e454af51331dd7b1d2a95bc5f on wub:master into dda5f6a2f0b0b3993616a1f98c27a500e5fcef3a on jasonslyvia:master.

@jasonslyvia There you go, is that all of it?

Cool, seems you helped to fix a bunch of linting issue too. Really appreciate it! I guess we're good to go.


change cla doc path

Codecov Report

Merging #70 (839c763) into main (aa67bfe) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #70   +/-   ##
=======================================
  Coverage   89.89%   89.89%
=======================================
  Files          15       15
  Lines         366      366
=======================================
  Hits          329      329
  Misses         26       26
  Partials       11       11

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa67bfe...839c763. Read the comment docs.

I have read the CLA Document and I hereby sign the CLA

recheck