How to remove duration and progress indicator in Android Auto when playing live stream

I'm working on an app that plays a live-stream for a radio station that also needs Android Auto support. I'm trying to find a way to hide the progress indicator and duration (which seems to default to 1:40) on the Android Auto UI, given it doesn't make sense for a live stream. Looking at https://github.com/androidx/media/issues/339 I assumed maybe there was a player/session command to control this, but I've tried a few with no luck so far. Does a command (or any other way to control this programmatically) exist?

We fixed https://github.com/androidx/media/issues/1256 in Media3 1.4.0, that sounds like the exact same issue. Which version are you using at the moment?

@jqi26 I managed to remove the progress bar by setting the METADATA_KEY_DURATION extra to -1 on MediaMetadata.extras.
But I have the same issue, @tonihei, in that I don't know what to set to remove the duration in Android Auto, which is just showing the duration of the live buffer which is not very useful nor user friendly.

@albinus-sc : Same question as above - is this still happening with 1.4.0 or are you on an earlier version? I believe we fixed this, so it would be good to know in which circumstances it still shows up the live buffer duration. If you have a reproducible example on the latest version, please share more details so we can take a look. You can also send test media links to<EMAIL_ADDRESS>and report back here if you don't want to share it publicly.

@tonihei Yes, we're using 1.4.1.
I'm not sure how to give a reproducible example. But I can say that our live buffer is about half an hour, and that half hour is what gets pasted into the duration on Android Auto. It works as intended in the media notification on Android 14. No duration is shown there, and no progress bar either.

@tonihei I have sent the HLS stream link we use to the provided email address.

Thanks @tonihei . No we're still on 1.3.1, can confirm I get the same result as @albinus-sc after upgrading.
1.3.1:

1.4.1:

Ideally it would be possible to get rid of the progress bar and time elapsed entirely? Though I see the bar is in the notification as well. Also tried seeing what happens in the Media3 sample when I stick our m3u8 file there; I get this:

Similarly the time elapsed keeps resetting to zero seconds, ideally these elements aren't there at all.

Hi the same issue for me, I added in this way but it has no effect
                val extras = Bundle().apply {
                    putLong(MediaMetadataCompat.METADATA_KEY_DURATION, C.TIME_UNSET)
                }
                val playbackStateBuilder = PlaybackStateCompat.Builder().apply {
                    setState(PlaybackStateCompat.STATE_PLAYING, C.TIME_UNSET, 1f, C.TIME_UNSET)
                    setActions(PlaybackStateCompat.ACTION_PAUSE)
                    setExtras(extras)
                }
                mMediaSession?.setPlaybackState(playbackStateBuilder.build())

            The same behaviour using a `-1` instead of `C.TIME_UNSET`. I am using legacy instead of Media3.

            POSSIBLE HINT: maybe it could be resolved by hiding the field using reflection ? @tonihei


tests-audio makefile issue (minor)

should the .o files go into out vs. example root?

also is this line needed in pong make?
rm -f *.o

Maybe? For single file projects (like tests-audio) I've been putting them in root since it doesn't cause that much clutter. It seems you might have done something similar for test-users, tests, terminal, multi-io, maze, and several others. I can switch it to go to an out folder though.

rm -f *.o was originally in Pong because the original, single player, pong only had one file and simply dumped the .o files in the root rather than an out folder. I guess I forgot to delete it when I made the change.

I think it's fine for smaller projects to put the .o files in the project root.
in some examples that had more files, i started to use an out folder for the build artifacts.  I think we have been inconsistent in the use of an out folders.  For example, we have: .o files, .js files, .wasm files.    Some are temporary, some are needed to execute the final build.  For the ones that need to execute the final build, i try to check them in to main (so that examples can be run. ).  But i doubt i/we have been consistant on that.  Currently we are committing some out/.js and some .wasm (not in out) to main.   We should probably clean up all the examples to be consistent.  There are various options, but I think probably the best is to put all build artifacts needed to run the example (.wasm, .js) into the example root, and all the temp build artifacts into out (and then out can not be committed to main).
What do you think?

That sounds good. Though, I feel like out should be called build instead. Out makes me thing "output" which would be better suited for the .wasm and .js files. Meanwhile something like "build" makes more sense for build artifacts and other temporary files.

My friend ChatGPT say: https://chatgpt.com/c/66fefe05-d62c-800a-89bf-67886fbf187f


Nothing happens

$ python runserver.py
[     pgoapi] [   INFO] pgoapi v1.1.7 - Copyright (c) 2016 tjado https://github.com/tejado
His writing it and nothing happens

Go to https://localhost:5000/

This site can not provide a secure connection
localhost sent an incorrect answer.

er, try this instead. My bad: http://<IP_ADDRESS>:5000/

This site is inaccessible
localhost does not allow the connection.
Do a Google search on localhost 5000.
ERR_CONNECTION_REFUSED
And console close for no error

I close and restart and now work 0.0
Ty for you help TheMaskedMonkey xD


Alt marked accepted without application

I don't know exactly the steps leading up to this, but the situation ended up as:

Main listed as on cooldown after being rejected due to skills
WHC user panel showed Main on cooldown, all alts listed as "please apply on main"
Reset the cooldown on Main via staff panel
Applied on Main
Accepted Main on staff panel
User display shows that Main as well as one alt are both accepted as members.

I don't believe this should be possible. In fact, I'm not even sure why the main was originally listed as on cooldown due to skills, seeing as they'd been removed from the community.
Timestamps for checking logs:

June 22, 2024, 9 p.m. WHC Community: Application Denied

Your application to the WHC Community on [alt1, alt2, alt3, alt4, alt5, Main, alt6, alt7, alt8, alt9] has been rejected.
	* Reason: Removed From Community
If you have any questions about this action, please contact WHC Community Coordinators on discord.

June 22, 2024, 9 p.m.	WHC Community: Application Denied (alt3 rejected...again?)
June 22, 2024, 9:01 p.m.	WHC application: Approved (alt4 accepted!?)
note: at this point, alt4 was not listed as accepted in user interface here, still says "please apply on main"
June 23, 2024, 3:07 a.m.	WHC application availability reset (alt6 reset)
June 23, 2024, 3:09 a.m.	WHC application availability reset (main reset)
June 23, 2024, 3:09 a.m.	WHC application: Application Submitted (main applied)
June 23, 2024, 3:09 a.m.	WHC application: Approved (main accepted)

It's unclear to me what exactly went wrong here, but something did. If alt4 was actually a member at 9:02pm, then the user panel was incorrectly showing it as a non-member. If alt4 was not a member at 9:02pm, then it was incorrectly accepted as a member without submitting an application after the main was accepted. Also, regardless, there should be no way that all characters were removed from the Community and then alt4 was accepted without a new application.

i think this is related to the long load period that was caused by trying to gather all the skills for all the apps all at the same time.
Ive moved the skill check window data to its own function that is only called when the button is pressed, so on the assumption that that lag was causing additional issues such as this, going to put a hold ont his issue until the new version is out and we can see if it continues

Cannot repro this. Given the behavior of v0.2.4, I'm inclined to think that it's not possible to produce anymore. And I tried.
Considering it closed. Will reopen if we find a way to trigger it again.


Provide programmatic access to template properties

Some elements of an application's user interface are managed by the UIKit framework, rather than by the application itself. For example, the UINavigationController class is responsible for creating and configuring its own UINavigationBar. As a result, it is not currently possible to style these elements using template properties.
MarkupKit should provide programmatic access to template properties so the appearance of these elements can be more easily managed by the application. To facilitate this, the following method will be added to LMViewBuilder:
+ (NSDictionary<NSString *, NSDictionary<NSString *, id> *> *)templatesWithName:(NSString *)name
    traitCollection:(UITraitCollection *)traitCollection;

This method will return an NSDictionary instance containing the contents of a named template. Any size class-specific properties will be resolved by the method before the dictionary is returned.
Further, the following method will be added to the NSObject+Markup category:
- (void)applyMarkupPropertyValues:(NSDictionary<NSString *, id> *)dictionary;

This will allow an application to easily apply template properties to UIKit-managed elements; for example:
override func viewDidLoad() {
    super.viewDidLoad()

    navigationController?.navigationBar.applyMarkupPropertyValues(LMViewBuilder.templates(withName: "ViewController",
        traitCollection: traitCollection)["navigationBar"]!)
    ...
}

Sample ViewController.json:
"navigationBar": {
    "barStyle": "black",
    "tintColor": "#ffffff",
    "barTintColor": "#444444"
}

This is done.


feature: use SyscallConn to get raw fd

Issues associated with this PR
Implement #328
Sign the CLA
Yes
Solutions
See diff
UT result
Sorry, no tests:(
Benchmark
Code Style

Make sure Goimports has run
Show Golint result

closed now


Feature/sector page models

Add models for industry + industry landing page.
Skeleton templates for industry page, industry landing page

Right, tests added - time for coffee before the runup to the next PRs :D


Have a visual for the ingestor microservice

Updated and done successfully :
https://github.com/airavata-courses/CloudElves/commit/9bd27586895932132bf86560e8c198a0a021a533


Changing variables in callbacks doesn't work in REPL

I expect a to be equal to 2 after I assign it in the callback:
ls> a = 1
1
ls> process.next-tick -> a := 2
undefined
ls> a
1

Am I doing anything wrong?

the REPL has some... scope weirdness


added roles translation

I've just noticed that only Brazilian Portuguese is supported. Sorry for the waste of time.


test(integration): skip specific test for iOS 11

see failure in Travis: https://travis-ci.org/algolia/algoliasearch-client-javascript/builds/374300255#L3665
This test can be skipped since really it's no problem if people get their results faster than expected.
I left the second timing test in there, since we still want the second request not to timeout
(this test is not run on PRs, so you won't really be able to see the difference in a PR)

(reviewed with you, agreed)


[Feature Request] Add some class for option group even if group-select prop is set to false

Explanation
If I want to apply something on class "multiselect__option--disabled" then it includes option group also.
Repo Link
https://codepen.io/akki-jat/pen/Nzrwar
Step to Reproduce
Just delete :group-select="true" prop and open the multiselect

Thanks! This seems like an easy change. :)

Related to this, the option groups should have a specific class regardless of if group-select is true or false. Right now, only the disabled class is applied when group-select is false.


Should there be a flag when adding a user to an alias for moderator status?

At this point when a user is added to a group via alias, they are standard users. We have the ability set someone as a moderator, should that be allowed via galias, or just reserved for the GUI.

Good idea, I like it.

There is now the ability to make someone and owner when you add them as well as promote and demote commands. There is not really a moderator status in the google API.


Do not convert non-addition ancestor

Given:
let text1 = 'ba';
let text2 = 'ar';
let isTheSame = text1 + 'r' === 'b' + text2;
When:
Refactoring enabling "String concatenation to template expression"...
Actual:
let text1 = 'ba';
let text2 = 'ar';
let isTheSame = ${text1}r${b${text2}};
Expected:
let text1 = 'ba';
let text2 = 'ar';
let isTheSame = ${text1}r === b${text2};
Operand types and operator should be checked.

Pull Request Test Coverage Report for Build 141

0 of 0   changed or added relevant lines in 0 files are covered.
104 unchanged lines in 10 files lost coverage.
Overall coverage decreased (-7.2%) to 73.374%

Files with Coverage Reduction
New Missed Lines
%

src/refactor/impl/formatJsdocs.ts
2
71.88%

src/refactor/impl/organizeImports.ts
3
50.0%

spec/refactors/organizeImportsSpec.ts
6
45.45%

spec/refactors/splitVariableDeclarationSpec.ts
8
50.0%

spec/typesSpec.ts
8
42.86%

src/refactor/impl/splitVariableDeclaration.ts
10
11.11%

src/types.ts
12
59.6%

spec/refactors/declareVariableSpec.ts
14
33.33%

spec/refactors/formatJsdocsSpec.ts
17
26.09%

src/refactor/impl/declareVariable.ts
24
5.08%

Totals

Change from base Build 131:
-7.2%

Covered Lines:
1258

Relevant Lines:
1537

💛  - Coveralls


Send and Receive need to be in their own functions

First issue

receive function implemented
send function will be implemented together with encryption


Update lightweight-charts to 2.0

https://www.npmjs.com/package/lightweight-charts/v/2.0.0
https://github.com/tradingview/lightweight-charts/releases/tag/v2.0.0

Fixed in #3


tag client services

In preparation to BC changes about to be merged in https://github.com/google/google-api-php-client-services/pull/25, we will update this version of the library to depend on google/apiclient-services:v0.5

LGTM


InfluxQL specification update

Bringing the InfluxQL spec up to date.  Currently a WIP.

@gunnaraasen this is looking great so far

@gunnaraasen it looks like your last commit actually got some of the merge conflict included. if you want to fix that up, we can go ahead and merge this.

@toddboom sorry, my branch got into a bad state. I think I managed to remove all the artifacts.


feat: increasing MAX_PUBLIC_DATA_UPDATE_REQUESTS_PER_CALL, removing hack

Increasing limit after discussion on slack.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#6739  👈
#6736
#6560
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @benesjan and the rest of your teammates on  Graphite

Benchmark results
Metrics with a significant change:

app_circuit_witness_generation_time_in_ms (MultiCallEntrypoint:entrypoint): 1,727 (+18%)
app_circuit_witness_generation_time_in_ms (SchnorrAccount:constructor): 1,445 (+46%)
app_circuit_witness_generation_time_in_ms (SchnorrAccount:entrypoint): 2,679 (+26%)
app_circuit_witness_generation_time_in_ms (Token:privately_mint_private_note): 1,578 (+38%)
app_circuit_witness_generation_time_in_ms (Token:transfer): 4,953 (+22%)
app_circuit_witness_generation_time_in_ms (Benchmarking:create_note): 1,410 (+47%)
app_circuit_witness_generation_time_in_ms (Token:unshield): 3,789 (+16%)
app_circuit_proving_time_in_ms (Token:transfer): 58,081 (+25%)
protocol_circuit_witness_generation_time_in_ms (root-parity): 89.7 (+88%)
protocol_circuit_proving_time_in_ms (private-kernel-init): 14,599 (+21%)
protocol_circuit_proving_time_in_ms (private-kernel-inner): 48,306 (+23%)
protocol_circuit_proving_time_in_ms (private-kernel-tail-to-public): 106,915 (+17%)
protocol_circuit_proving_time_in_ms (private-kernel-tail): 43,184 (+18%)
protocol_circuit_proving_time_in_ms (public-kernel-tail): 185,319 (+20%)
protocol_circuit_proving_time_in_ms (root-rollup): 22,534 (+16%)

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
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,732
1,555
709
746
767

proof_construction_time_sha256_30_ms
11,442
3,076
1,379
1,426
1,457

proof_construction_time_sha256_100_ms
43,750
11,765
5,494
5,556
5,356

proof_construction_time_poseidon_hash_ms
236
80.0
58.0
90.0
148

proof_construction_time_poseidon_hash_30_ms
5,745
1,564
722
797
792

proof_construction_time_poseidon_hash_100_ms
11,374
3,044
1,371
1,419
1,436

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,464
9,476
9,452

l1_rollup_execution_gas
616,105
616,117
616,093

l2_block_processing_time_in_ms
1,285 (-2%)
4,791 (-2%)
9,529 (-1%)

l2_block_building_time_in_ms
46,568 (+1%)
185,048 (+1%)
370,900 (+2%)

l2_block_rollup_simulation_time_in_ms
46,392 (+1%)
184,389 (+1%)
369,589 (+2%)

l2_block_public_tx_process_time_in_ms
25,037 (+1%)
104,937 (+1%)
215,276 (+2%)

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,466 (-1%)
14,521

node_database_size_in_bytes
14,479,440
21,307,472

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.

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.4 (-1%)
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.604 (-1%)
0.521
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.4 (-1%)
76.4
246 (-1%)
478
925 (-2%)
1,836 (-1%)
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.495 (-1%)
0.471
0.446 (-1%)
0.446
0.439 (-1%)
0.438 (-1%)
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
58.0 (-1%)
113 (-1%)
354 (-1%)
703
1,379 (-1%)
2,749 (-1%)
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.502 (-1%)
0.505 (-1%)
0.480 (-1%)
0.482
0.477 (-1%)
0.477 (-1%)
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 |  |
| - |  |


selector wildcard support for Pool Cluster

Pool cluster throws errors when wildcard selector is used as prefix or in the middle of selector string.
For example, I have the following setup:
> var mysql = require('mysql'  )
> var poolCluster = mysql.createPoolCluster();
> var config = { user: 'root', host:'<IP_ADDRESS>', password: '....', database: 'test' }
> poolCluster.add('MASTER', config);

The following throw errors:
> poolCluster.getConnection('*ER', function (err, connection) { console.log( err ) });
{ [Error: Pool does not exist.] code: 'POOL_NOEXIST' }
> poolCluster.getConnection('MA*ER', function (err, connection) { console.log( err ) });
{ [Error: Pool does not exist.] code: 'POOL_NOEXIST' }

Although, this works
> poolCluster.getConnection('MA*', function (err, connection) { console.log( err ) });

I think, all of selectors match MASTER, so they should technically work.

Hi @siddo420 I removed the "[Bug]" from the issue title because this is not a bug :) You're just asking for a feature that does not exist. You're welcome to make a pull request to add this new feature, though :) ! Please include the use-cases and proposal for why this should be a feature as well.

A better of way doing this is to support regex in patterns but that can break existing code.
Would you be OK with that?

@ifsnow added support for regular expressions and I added support for the wildcard to be anywhere in the string, so I think all the bases with this request should be covered now :)

when will this be included in main branch?
I've tried 2.13.0.

seems to work now ..thanks


BE can't be grayscale upgraded

Describe the bug
BE can't be grayscale upgraded. After I upgraded one BE from <IP_ADDRESS> to latest version. the query will failed.
ERROR 1064 (HY000): Ocurrs time out with specfied time xxx MILLISECONDS
or
ERROR 1064 (HY000): failed to send batch

To Reproduce
Steps to reproduce the behavior:

upgrade one  BE from <IP_ADDRESS> to latest version
query

Additional context
The latest BE warning logs:
W1109 14:43:35.397363 28981 data_stream_sender.cpp:125] failed to send brpc batch, error=No such method, error_text=[E1002][10.24.
104.124:8060][E1002]Fail to find method=doris.PInternalService/transmit_data

The <IP_ADDRESS> BE warning logs
W1109 14:43:37.406872 10384 data_stream_sender.cpp:149] failed to send brpc batch, error=No such method, error_text=[E1002][<IP_ADDRESS>:8060][E1002]Fail to find method=palo.PInternalService/transmit_data

The brpc method name used by be contain package name. When we change our package name from palo to doris, the rpc method name is changed too. Then old version BE send method name like palo.rpc_method, and new version BE doesn't know this method cause of their methods name are like doris.rpc_method.
So, For compatible with old version, I reserve old RPC service palo.PInternalService, and add a new RPC service doris.PBackendService, which are implemented the same. And new version BE also use palo.PInternalService to call other BE, which can be old version or new version.
FE's RPC client have no this problem, because their RPC method have not include package, so, changing package have no influence with it.

It's Great!  Thanks you.

@kangkaisen I have merge my patch to master, now you can fetch and try. Looking forward to you feedback.

@imay I have tested this patch, it resolved this issue. Now, the latest code could support BE grayscale upgrade. Thanks you very much！


update cloud 123

Description of PR
How was this patch tested?
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 53s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

_ trunk Compile Tests _

+1 :green_heart:
shadedclient
33m 37s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
shadedclient
22m 38s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
asflicense
0m 46s

The patch does not generate ASF License warnings.

59m 47s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4617/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4617

Optional Tests
dupname asflicense codespell detsecrets

uname
Linux e35f342cd2a6 4.15.0-175-generic #184-Ubuntu SMP Thu Mar 24 17:48:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d497bc0fcb060e0e026e4dd6d61a30bcddfe76c5

Max. process+thread count
607 (vs. ulimit of 5500)

modules
C: . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4617/1/console

versions
git=2.25.1 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


[Jenkins] Update python integration tests with enviroment variables

Similar to Java integration tests, update python integration tests with env variables

Added environment variables GCP_PROJECT, REGION, GCS_STAGING_LOCATION, SUBNET similar to java integration tests.


Use of the ITK3 to support GP Connect Messaging page

"...to provide message reliability facilitate alignment with practice workflow." I think this should say "...reliability and facilitate..."
"...builds on the FHIR Messaging framework by through..." don't think "by" is needed
Third bullet needs a full stop at the end
"Please refer to the messaging capability and messaging use case pages..." messaging capability? do you mean Send Document capability?

Covered off in https://github.com/nhsconnect/gpconnect-messaging/commit/26572de88d85055601edbb1f2959c55c191dc124
Final comment not actioned, not being specific to Send Document will allow other capabilities to be added with re-addressing this section in the future.


Adds OGL 1.0a to custom licenses

We were talking about custom license support in the League of Foundry Devs Discord last month, and how there isn't a clean Open Game License text to pull from anymore.
This is the one I'll be submitting to SPDX for approval soon (proposal repo). Note: the Copyright notice for the SRD you're using, and any other content sources, still need to be added to the bottom.

Looks good! :rocket:

You can download the binary from here, which includes support for the OGL license :smile_cat:
https://github.com/sean-clayton/licensor/actions/runs/1034676421


Resize the screenshots on README and place the images in 1 row

Make the two screenshot little bit smaller in size and put the in the same row.
Instructions:

Fork the repo
Resize the images
Do not delete the original images. Just upload resized images
Change original images by resized images
Update the README by placing two images in one row
Make Pull Request

Make sure you leave a comment on this issue and wait until you are assigned. Then you can create a PR.

Could resizing the image using html tags like <img src="car.png" alt="car" width="200"/> work instead of resizing & reuploading the images?

Anyways, I've tested it and it works. If you are interested in this approach, you can assign me the issue and I'll gladly make the PR.
First PR to an open source project btw :)

Assign me Pls  :)

Hey @maynouf you can start working on the project with your idea. Please make sure to add a little bit space between two images.


Prevent multiples of same deal card from populating hotdeals section

Can't do this, as there are sometimes multiple stores (eg: e-bits pc store w/ 2 locations) that offer the same deal.


Restrict movement to left-right direction, limit rotation and allow some up-down movement

I am not sure what exactly is meant by this. Could you elaborate @Benjozork

The concept of the game is not open-world so we do not need full movement out of the level's bounds. Only sideways with slight rotation, and some vertical movement for battles.

Started as of 5f5185696b8dd5aad98bef45ab5755da01d8e4a1

More progress as of d06178a10cd7b15298b7d61222fa36dc8f671c00


[WIP] Average background media color for page background

Summary

Relevant Technical Choices

To-do

User-facing changes

Testing Instructions

Fixes #

I'm always hesitant with logic appearing in multiple places (here extracting baseColor happening in 2 very different but similar places), but I guess it's necessary in this instance for backward compatibility.

Yep, was trying to think of a better alternative but didn't have one yet. One option could be not assigning the base color in the media library at all and only doing it when combining two elements -- would have it in one place (leaving only the logic for the current backward compatibility) but would make combining a bit slower (since the base color always needs to be extracted first). In this case, perhaps it's OK to still leave it in two places.

Could we try to add a karma test for this one? I'd love to see that it works all the way from adding an image to the resulting AMP output.

Hm, since the Karma tests are taking a long time already now to run, I was actually purposefully adding it to already existing Karma tests since setting the color is one part of setting the background, even though we added it separately. Currently, there are two tests where the added baseColor is being checked + separate unit tests to ensure that if it's present in the props, it will be added to the HTML properly as well.
Let me know if you still think it's worthwhile trying to add a separate Karma test focused on this one feature specifically.

Verified in QA
example (while loading)


查找函数功能只对js有效

VSCode Version:0.10.11
OS Version:win7

Steps to Reproduce:

Translates to: Lookup functions are only valid for JS

this translation is almost right. I guess “查找函数”  means “go defination”？Could you give more details ，such as operation steps or shortcuts @chwentao？

If it's about Go to Definition (f12) not working in another language, which language(s) in particular would be good.

go to symbol and f12  function, only work in js language.

I believe go to symbol generally requires an extension to work, for example the C# extension https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp
Closing this, feel free to open a new issue if you have a particular language you're concerned about. It will likely be up to extensions to add this behavior though.


Request for Native Mobile SDK Cart Integration Documentation

We are working on integrating Bambuser's shopping cart feature using the mobile SDK (for Android and iOS). While we have found the documentation for web here https://bambuser.com/docs/live/cart-integration, it seems there isn't equivalent documentation that outlines how to achieve similar functionality on native mobile apps.
We would like to request documentation or guidance on how to:
Provide detailed product data from the mobile side (similar to the PROVIDE_PRODUCT_DATA event in the web documentation) on to integrate the player with our internal API to fetch the product enrichment fields and use them in cart.

Hello Emailvenkatm! We have a quick guide documented in this PR
Let me know if it has enough guidance for you to start integrating the cart into your app, or if you need more detailed information.

Thanks @zeyadsadaqa


Sample commands don't work

I copied the command off the page and pasted it into the command prompt:
az role definition list --custom-role-only true --output json --query '[].{roleName:roleName, roleType:roleType}'

The hit enter and got this:
argument --query: invalid jmespath_type value: "'[].{roleName:roleName,"
To learn more about --query, please visit: 'https://docs.microsoft.com/cli/azure/query-azure-cli'

az version is showing this:
{
  "azure-cli": "2.30.0",
  "azure-cli-core": "2.30.0",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {
    "resource-graph": "1.1.0"
  }
}

Any ideas?

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

ID: 9afab524-67c2-2e76-fd7a-46238cb9d249
Version Independent ID: ae2da577-6026-f322-1c09-dbcc6068c01a
Content: Transfer an Azure subscription to a different Azure AD directory
Content Source: articles/role-based-access-control/transfer-subscription.md
Service: role-based-access-control
GitHub Login: @rolyon
Microsoft Alias: rolyon

@martingbrown Thank you for your feedback! We will review and update as appropriate.

@martingbrown This is a known issue with Powershell.exe as per Azure/azure-cli#11320 . If you pass the parameters in quotes it should work .

The same works in Azure portal without an issue. Hope this helps . There is a great explanation for the same on stackoverflow as well .


"showOutput": "silent" not working

VSCode Version: Code - Insiders 1.13.0-insider (afe47dc84467b487ce0079ff72f55e7ef4f7ebca, 2017-05-30T10:34:18.253Z)
OS Version: Darwin x64 15.6.0
Extensions: none

Testing #27471
https://code.visualstudio.com/docs/editor/tasks says "silent" should reveal if there are no output matchers. This doesn't reveal for me:
{
  "version": "2.0.0",
  "command": "echo",
  "isShellCommand": true,
  "args": [
    "Hello World"
  ],
  "showOutput": "silent"
}

Same with "terminal": { "reveal": "silent" }, so maybe this simply has changed, although I can't find a difference between "silent" and "never".

Moving to June since 0.1.0 will stay the default for May.

Fixed for June release.


Issue on Safari : Promise Rejection: ReferenceError: Cannot access uninitialized variable.

Hi,
Thank you for the nice library. Sadly, it seems there is an issue on Safari.
Please refer to

https://github.com/sveltejs/kit/issues/12406
https://github.com/cge-taal/sveltekit-safari-ssr-example

The example repository above is to illustrate the problem via a small reproducible example. However, in a rather big code base, libauth is the only dependency which is having issues in Safari, failing with Promise Rejection: ReferenceError: Cannot access uninitialized variable..
Therefore I imagine it has to do with how libauth is packaged, and not something intrinsic to vite / sveltekit.
Would appreciate it if you could take a look.
Thanks

Is this a bug (or rather, a missing feature) in Svelte? https://github.com/sveltejs/svelte/issues/5501

Hi @bitjson , thank you for the feedback. Yes I think you might be right. Please excuse the noise :)

Hi @bitjson, according to this comment ( https://github.com/sveltejs/kit/issues/12406#issuecomment-2211159175 ) "Libraries and even SvelteKit need to be refactored to avoid the use of top-level awaits in the browser."
What is your take on that please? Is it feasible to load WASM routines in your library without the use of "top-level awaits in the browser" ?

I realize I'm a bit late to this party, but was experimenting with Svelte(Kit) recently.
I was only able to get this working through a bit of trial+error (aided by scattered Google searches). In case it helps anyone in future:
For vite.config.js, I did:
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';
import { nodePolyfills } from 'vite-plugin-node-polyfills';

export default defineConfig({
	plugins: [sveltekit(), nodePolyfills({
	  // This was for the electrum-cash library... unrelated, but copying here in case pertinent as example to others.
	  include: ['event', 'net', 'tls'],
	})],
	build: {
	  target: "es2022"
	},
	esbuild: {
	  target: "es2022"
	},
	// NOTE: This was important! Top-level await would not work without this!
	optimizeDeps:{
	  esbuildOptions: {
		target: "es2022",
	  }
	}
});

... and in svelte.config.js I did:
const config = {
        // ...
	viteFinal: async (config) => {
		if(!config.build) {
			config.build = {};
		}
		config.build.target = ['esnext'];
		return config;
	}
        // ...
}

I think I recall reading that svelte.config.js will overwrite some of the build configurations used in vite.config.js (because it uses some custom build setup and depending upon Vite's config would break this). Hence why we need to muck about with the viteFinal object there.

Hi @jimtendo , what a nice surprise to see movement on this. I did not get round to trying more things yet, so I'm excited to see if your solution works for me too. Will report back in the next days. Thanks for sharing

I could not help myself and had to try quickly. Are you sure your changes allows it to work in Safari? Please see the screenshot attached for the error in Safari.

My config was already working to allow libauth to be used in SvelteKit. This this ticket is really only to report issues with Safari. As someone in the SvelteKit community suggested, given there is a bug regarding top-level async await in Safari, the only real solution would be to refactor libraries, in this case libauth, to not use top-level async await, unfortunately.

I'm very sorry, I'd actually completely missed that your issue was Safari!
I did not test that - but suspect I would've bumped into the same issue you have.
Not sure if it's of help to you (I kind of doubt it would work), but there is a Top-Level-Await polyfill I've used on Quasar projects successfully to support old versions of KDE's Falkon browser: https://www.npmjs.com/package/vite-plugin-top-level-await
No idea if that would work on your case as it seems that Safari does support Top-Level-Await already (so polyfill probably wouldn't apply itself).

Hi @jimtendo , not worries at all - thanks for trying to help.
If you are curious, I don't need a viteFinal section in my svelte.config.js, and my vite.config.ts has
import { sveltekit } from '@sveltejs/kit/vite'
import { defineConfig, type UserConfigExport } from 'vitest/config'
import browserslistToEsbuild from 'browserslist-to-esbuild'

export default defineConfig({
  ...,
  target: browserslistToEsbuild(),
  plugins: [sveltekit()],
  optimizeDeps: {
    esbuildOptions: {
      target: 'esnext',
    },
  },
  build: {
    target: 'esnext',
    commonjsOptions: {
      include: [ ..., /node_modules/ ],
    },
  },
} as UserConfigExport)


ACL plugin cache invalidation failures

We've begun having problems with Kong's in-memory cache updating after ACL rules are updated.  What's tricky is that this seems to be happening in a non-deterministic way.
We're performing the following sequence of events:

Verify that a consumer exists (GET /consumers/id)
Verify that an API exists (GET /apis/id)
If not, create a new API (POST /apis)
Add a new group to a consumer's ACL plugin (POST /consumers/id/acls)
Add the key-auth plugin to the new API (POST /apis/id/plugins)
Add the ACL plugin to the new API with the new group (POST /apis/id/plugins)

The first several times we perform this sequence, we can successfully authenticate and authorize requests to our newly created APIs.  However, at a certain point we begin receiving 403 errors when making requests to newly created APIs, with the message "You cannot consume this service" (returned by the ACL plugin).
Once this happens, all new APIs we create suffer from the same problem.  When we retrieve the cached ACL key (GET /cache/acls:consumer_id), the payload returned doesn't include the newly created ACL groups.  Hitting the live admin endpoint (GET /consumers/id/acls/) does include the newly created ACL groups. Restarting Kong or manually hitting DELETE /cache remedies the problem.
In short, all this points to a failure in Kong to invalidate its in-memory cache when ACL rules are updated on the consumer.  The fact that it takes a variable number of hits to produce this behavior suggests a possible race condition?
 I am adding a second API (with key-auth and ACL plugins) and it also works. What operations should I do from now on to replicate your problem?

@thefosk Thanks for looking at this.  I just wrote a standalone Python script that mimics our application's interaction with the admin API:
https://gist.github.com/msmathers/94daa1069f80ee4ee134
Every time I run this script I'm able to authenticate & authorize against the first API I create, but then all requests against subsequent APIs fail with a 403 status.  If I manually delete the Kong cache or restart Kong, the requests begin working.
Let me know if you need anything else, thanks!

@msmathers I have found the bug and fixed it. The fix will show up in v0.7.0.


update release

please there aren’t any releases here.  can we update v.1.0.28 to 1.2.0 (https://github.com/superkhau/lice/tags)?

@superkhau think we need another release


[Adventure] Broken NPC Trainer

Describe the bug
NPC Trainer is unable to do battle
To Reproduce
Steps to reproduce the behavior:

Go to -157, -157 in Adventure
Throw pokeball at Austin, Lvl: 5 Trainer NPC
Select pokemon to use in battle
Stuck in screen waiting for Austin to choose their single pokemon

Expected behavior
Battle commences
Screenshots

Username:
ILoveYou
Server name (all applicable):
Orion
Logs:
N/A
Additional context
N/A

Combining with https://github.com/NebulaMC-GG/Bugs-and-Issues/issues/1842 - closing!


Document on how to apply secure vault when building an Docker image of WSO2 MI

Description:
There should be a guide on how to apply secure vault when you are building Docker images of WSO2 MI. If that is not needed when deployed with K8S/Docker, we need to mention it clearly as well.
(In general, I feel all MI related docs are VM oriented still and we have not thought of the experience of a customer who will be doing deployments using images)
Affected Product Version:
MI 1.1.0
OS, DB, other environment details and versions:
N/A
Steps to reproduce:
N/A

Closing this issue now, as the feature and docs are completed for the EI 7.1.0 release.
An additional improvement will be handled by [2].
[1] https://ei.docs.wso2.com/en/7.1.0/micro-integrator/setup/security/encrypting_plain_text/
[2] https://github.com/wso2/docs-ei/issues/2131


@since should be used in public API

It's very common to miss @since tag in Javadoc for elementes (annotations, methods, ...) in the Gradle public API. Due to that it's quite unpleasant for a plugin author to check with which version his/her plugin is compatible using for example @CacheableTask.
Expected Behavior
Javadoc for public API (annotations, methods, ...) contains @since tag (at least for new elements adding in Gradle 4.x+)
Current Behavior
No information in which version given API element has been added.

Usually we are doing a relatively good job in adding and checking @since and @Incubating annotations. We also started to add more automation around these aspects though there's definitely room for improvement.
@lptr Could you please add the @since and @Incubating annotation to @CacheableTask?

We are actively working on improving the points you mentioned above and track this with internal issues. I am going to close this issue for now. Thanks for speaking up on these issues.

Great to hear. Probably I just had bad luck with some elements I was looking at in the past.

@szpak Certainly let us know if you find other place where @since is missing.


date: fix date -f dates.txt is failing

This commit is a trivial followup for:
https://github.com/uutils/coreutils/pull/4917
and
https://github.com/uutils/parse_datetime/pull/12
The functionality to parse the datetime was moved into the parse_datetime crate and the only (tiny) piece left is to call it from date.
It also adds the test-case from the original issue. I did not include the two tests from PR#4917 because they appear to work even without this change. I am happy to include them of course if prefered.
Closes: #4657
Thanks to Ben Schofield

nice to see you here ;)

Thanks!


Spanish translation

Mexican and EU Spanish

Hey! We currently use Crowdin for translations: https://crowdin.com/project/lootr

Yeah sure, no problem

Awesome, thank you so much! This means that it automatically gets applied to all of the different versions consistently.

I already updated all of the spanish translations in Crowdin it should be 100% translated across all of the versions now

@TheLegendofSaram Sorry for the delay! I thought I'd actually already done this until just now. I believe it should be set up now!


Fix jitclass method inlining and avoid unnecessary increfs

This change addresses issues #2166 and #3305 . Numba wasn't able to inline jitclass' methods, because the their definitions weren't available at the compile time. When a function is lowered, the related libraries should be added using CodeLibrary.add_linking_library, which wasn't happening for jitclass. This patch adds this functionality for methods, properties and constructors.
There is one more subtle problem. Unnecessary refcounts usages are removed on the level of basic blocks. This makes sense, since analyzing across bb borders would be much more involved. However, this approach can only work after CFG is consolidated enough for inc/ref counts to be reliably grouped. At the same time, after removal of the NRT refcount calls there are additional optimizations possible, i.e. more aggressive loop unrolling. So, to achieve the best performance we would have to run the optimizations after NRT refcount removal again, with trade-off of the slower compilation. A more fine-grained approach is thinkable, with more carefully selected passes to run before and after NRT optimization, but I wasn't able to determine the perfect combination.
Note that improving inlining also improves unnecessary NRT refcount detection since the calls are more likely to the placed in the same block.
@numba.jitclass([
    ('data', numba.uint32[:]),
    ('pos', numba.uint64)
])
class Container:
    def __init__(self, size = 10 ** 6):
        self.data = np.zeros(size, dtype=np.uint32)
        self.pos = 0

    def append(self, el):
        self.data[self.pos] = el
        self.pos += 1

@numba.njit
def append_batch():
    N = 10 ** 6
    c = Container(N)
    acc = 0
    for i in range(N):
        c.append(i)
    return c

For this example having an additional optimization pass makes a difference of around 30% (3.3ms vs 2.6ms). On the other hand it slows down compilation considerably. I would be glad to hear, what you would consider the best approach here.
Finally, performance numbers from the benchmark in #2166:
With current master:
<class 'int'>
 function_function  0.000001 0.000001 0.000001 0.000001
 method_function    0.000002 0.000002 0.000004 0.000003
 method_method      0.000164 0.001591 0.016329 0.159769
 function_method    0.000156 0.001543 0.015927 0.159938
<class 'list'>
 function_function  0.000007 0.000007 0.000007 0.000007
 method_function    0.000009 0.000008 0.000008 0.000008
 method_method      0.000174 0.001619 0.016244 0.160375
 function_method    0.000198 0.001557 0.015969 0.158437

With this patch

<class 'int'>
 function_function  0.000001 0.000001 0.000001 0.000001
 method_function    0.000001 0.000001 0.000001 0.000001
 method_method      0.000001 0.000001 0.000001 0.000001
 function_method    0.000001 0.000001 0.000001 0.000001
<class 'list'>
 function_function  0.000008 0.000007 0.000006 0.000006
 method_function    0.000008 0.000007 0.000006 0.000006
 method_method      0.000008 0.000006 0.000007 0.000006
 function_method    0.000008 0.000007 0.000007 0.000006

Note: this PR doesn't add any tests or benchmarks. If you have any suggestions, which part I should test and/or benchmark, I'll gladly  add it.

FYI, here's showing the difference of running optimization twice vs once on the append_batch code in the PR description:
Run twice:
cfg_opt_twice.pdf
Run once:
cfg_opt_once.pdf

As for benchmarks, can you add them to https://github.com/numba/numba-benchmark/tree/master/benchmarks?  We use ASV for benchmarking.

Hi @sklam,
thanks for taking a look. I incorporated your comments and removed the second optimization pass.
Yes, the loop becomes longer because of unrolling, which increases the performance a bit, at least on my machine. It can only be done correctly after everything's inlined, so for optimal code you'd do (normal optimizations)->(remove refcnt)->(unroll loops). I absolutely agree that running whole optimization second time is not the way to go.
I'd say we need a better way to optimize inc/dec-ref call across the basic blocks. This can be seen as unrelated to this PR, although the inlining would benefit from having fewer calls inside methods.
I'll look into adding benchmarks to numba-benchmark (wasn't aware of that repository).

@sklam I sent a PR to the benchmarking repo: https://github.com/numba/numba-benchmark/pull/8 . Just out of curiosity: do you publish the ASV results/history for numba somewhere?

@alendit, they are published to http://numba.pydata.org/numba-benchmark/


Added Progress View While Loading Content

Added support to show a progress view while loading..

Closing this PR due to inactivity. Feel free to reopen if you're ready to pick up the feedback and updating with main!


ZEPPELIN-544 ] After the restart when setting bug fixes interpreters note paragraphs state.

What is this PR for?
Restful api - call upon the setting / interpreter id type,
The problem occurs in the status of running Paragraphs.

Paragraphs status code changes and restart missing

What type of PR is it?
Bug Fix
Todos
Is there a relevant Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-544
How should this be tested?
Paragraphs running after interpreter config change, save -> click okay on restart dialog
Screenshots (if appropriate)
before

after

Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

Great for finding missed spot!

@HeartSaVioR  Thank you for Feedback. have a nice day!

Minor: How about extracting whole synchronized block to new private method?
Actually setPropertyAndRestart() and restart() takes same logic except setting additional parameter and calling saveToFile().
setPropertyAndRestart() can call saveToFile() safely when new method is executed without InterpreterException. So new private method doesn't need to take care about safeToFile().
Next concern is that how we can unify logic whether two parameters are presented or not.
It would be achieved easily with null check, but someone can think it's not beautiful.
So I'd like to hear our opinions about this suggestion.

@HeartSaVioR
Your horse may have a point.
But this is a PR for a bug-fix.
I do not want to put undue changes here.
I am concerned that a new bug occurs.
Once I quit the modification here.

@HeartSaVioR
Your horse may have a point.
But this is a PR for a bug-fix.
I do not want to put undue changes here.
I am concerned that a new bug occurs.
Once I quit the modification here.

@HeartSaVioR
I agree with your opinion.
But this is a PR for a bug-fix.
I do not want to put undue changes here.
I am concerned that a new bug occurs.
Once I quit the modification here.

@HeartSaVioR
I agree with your opinion.
But this is a PR for a bug-fix.
I do not want to put undue changes here.
I am concerned that a new bug occurs.
Once I quit the modification here.

@cloverhearts OK, Don't worry. I'll address it to another issue. :) Happy new year!

@cloverhearts OK, Don't worry. I'll address it to another issue. :) Happy new year!

@HeartSaVioR Happy new year, HeartSaVioR!

@HeartSaVioR Happy new year, HeartSaVioR!

Forgot to say LGTM. :)

Forgot to say LGTM. :)

LGTM and merge if there're no more discussions


Ensure that YAML fields are sorted

This closes #235
A sample spec would now output as:
---
cdiVersion: v0.3.0
kind: example.com/class
devices: []
containerEdits:
  deviceNodes:
  - path: /dev/foo

instead of:
---
cdiVersion: v0.3.0
containerEdits:
  deviceNodes:
  - path: /dev/foo
devices: null
kind: example.com/class

Thanks for the points that you raised, @klihub. The main motivation for struct-based ordering is the human readability implied by the ordering. Note that the underlying yaml implementation is still gopkg.in/yaml.v2.
Let me take some time to better address / answer your questions.

Thanks for the points that you raised, @klihub. The main motivation for struct-based ordering is the human readability implied by the ordering.

Sure, I understood that and I'm all for it. Just wanted to make sure that nothing hits us by surprise as a side-effect.


Add LogElements as a Beam PTransform

Closes #23016
Adds LogElements as a valid PTransform with unit tests and updates the previous references to the standalone transform in the katas section.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @tvalentyn

Re Lint errors, you cand find them in Details -> ConsoleOutput, e.g. https://ci-beam.apache.org/job/beam_PreCommit_PythonLint_Commit/16316/consoleText
See also: s.apache.org/beam-python-dev-wiki that mentions lint/autoformatting tools

@tvalentyn Thank you for the quick response! All points have been fully addressed except for this one, where I kindly asked you to clarify a piece of information before proceeding.

Thanks, this looks good to me. Test failures are unrelated.

cc: @damccorm fyi.


⚠ Account Information API has degraded performance

In 89b258d, Account Information API (https://accountinformation.roblox.com) experienced degraded performance:

HTTP code: 503
Response time: 5277 ms

Resolved: Account Information API performance has improved in 611fed6.


Open in new tab is not working using Firefox

Describe the bug
I clicked on "Open in new tab button" and in the newly opened tab it shoes "Unable to connect to local-corp.webcontainer.io".
I tried it in google chrome and it's working as expected without any issue
Link to the blitz that caused the error
https://stackblitz.com/github/remix-run/react-router/tree/main/examples/modal?file=src%2FApp.tsx
Steps to reproduce

click on open in new tab
it says 'Unable to connect to the project'

Expected behavior
open the output in a new tab
Parity with Local

[ ] I have run the project in my local machine and I could not reproduce the issue.

Screenshots
No response
Platform
Browser name  = Firefox
Full version  = 105.0
Major version = 105
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0
performance.memory = undefined
Hash = 912cb019f8b62040b90085f00ac69aca69f51e29

Additional context
No response

same, I only get this:

It seams it's a duplicate
Duplicate of #811

Yep, this is related to storage partitioning which has been rolled out in Firefox but not Chrome yet. As mentioned in #811 we are working on a fix already. Thanks for reporting this issue. I am going to close this as we are tracking this in #811.


Fixes #1833, Support for Powershell execution in Post deployment action

Partial deployment logs for verification
remote: .........
remote: Executing CMD/BAT - 'D:\home\site\deployments\tools\PostDeploymentActions\test.cmd'
remote: 'D:\home\site\deployments\tools\PostDeploymentActions\test.cmd' executed successfully
remote: Executing PS - 'D:\home\site\deployments\tools\PostDeploymentActions\test.ps1'
remote: 'D:\home\site\deployments\tools\PostDeploymentActions\test.ps1' executed successfully
remote: Finished successfully.
remote: Deployment successful.

Fixed in 49cfa95e845348303346105eaf03422c96636ae9


Fix downloading created COMBINE archives

The bug was introduced in cd2840d98d84f13eab34cea479a09da23187fe14.

:tada: This issue has been resolved in version 2.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Make all forwardRef tests pass

Ported this PR over from the ceviche repo.

Coverage remained the same at 100.0% when pulling efce2f39bc8b293067de33930c5e5d098c064afb on forward_fix_tests into 1566a31f32b8657172b44b20b0182c9f56de67b1 on master.


feat: memtable filter push down

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?
This PR enables filter pushdown for memtable so that irrelavant time series can be skipped.
Checklist

[ ]  I have written the necessary rustdoc comments.
[ ]  I have added the necessary unit tests and integration tests.

Refer to a related PR or issue link (optional)

I think we should add some benchmark for this feature.

I think we should add some benchmark for this feature.

I've run an informal test against this branch, it can improve by around 70% performance in scanning memtable.

I think we should add some benchmark for this feature.

I've run an informal test against this branch, it can improve by around 70% performance in scanning memtable.

Cool. It would be beneficial for future improvements if we include a benchmark program in the repository.


conda_deps packages being overwritten with PyPi equivalents.

I have the following tox.ini file:
[tox]
envlist = py38, py39, py310, pylint, format, flake8, docs
skip_missing_interpreters = true
isolated_build = true

[testenv]
deps =
    pytest
    pytest-xdist
    pytest-cov
conda_deps =
    scikit-rf
    numpy
    scipy
conda_channels =
    defaults
    conda-forge
conda_install_args =
    --force-reinstall
    --override-channels
conda_create_args =
    --override-channels
setenv = CONDA_DLL_SEARCH_MODIFICATION_ENABLE=1
commands =
    py.test --basetemp={envtmpdir} -vv --cov=pybert \
            --cov-report=html --cov-report=term-missing tests
{snip}

But, after I run: tox -e py38 -r, I find that I have PyPi versions of: scikit-rf, numpy, and scipy, installed in the test environment:
(pybert-dev)
capnf@DESKTOP-G84ND7C MINGW64 ~/Documents/GitHub/PyBERT (add-tests)
$ conda activate .tox/py38/

(C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38)
capnf@DESKTOP-G84ND7C MINGW64 ~/Documents/GitHub/PyBERT (add-tests)
$ conda list numpy
# packages in environment at C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38:
#
# Name                    Version                   Build  Channel
numpy                     1.23.3                   pypi_0    pypi

(C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38)
capnf@DESKTOP-G84ND7C MINGW64 ~/Documents/GitHub/PyBERT (add-tests)
$ conda list scipy
# packages in environment at C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38:
#
# Name                    Version                   Build  Channel
scipy                     1.9.2                    pypi_0    pypi

(C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38)
capnf@DESKTOP-G84ND7C MINGW64 ~/Documents/GitHub/PyBERT (add-tests)
$ conda list scikit-rf
# packages in environment at C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38:
#
# Name                    Version                   Build  Channel
scikit-rf                 0.24.1                   pypi_0    pypi

I see my conda_deps in the log:
py38 recreate: C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38
py38 installcondadeps: scikit-rf, numpy, scipy
py38 installdeps: pytest, pytest-xdist, pytest-cov
py38 inst: C:\Users\capnf\Documents\GitHub\PyBERT\.tox\.tmp\package\1\PyBERT-4.0.0.tar.gz

Why are they being overwritten with Pip / PyPi equivalents?

This is because you have pinned the version of those dependencies in pyproject.toml and if these are not satisfied when conda installs them from conda_deps then they are overridden by pip when your package is installed.

This is because you have pinned the version of those dependencies in pyproject.toml and if these are not satisfied when conda installs them from conda_deps then they are overridden by pip when your package is installed.

Thank you, @AntoineD !
Is there anywhere in the log where I'm alerted that conda failed to install the requested versions and that pip will be saving the day?

conda ignores the dependencies defined in packaging descriptions for pip like pyproject.toml, you may see that those dependencies have been installed twice by adding -v to the tox command line.
If you intend to create a pip installable package , you do not need conda here.
If you need to use conda anyway, then you may use the very same version pinning in tox.ini as they appear in pyproject.toml.

Thanks, @AntoineD !
Using a freshly deleted and recreated .tox/py38/ environment, I tried the following experiment, which I expected to fail:
$ conda install -c defaults -c conda-forge --override-channels python=3.8 numpy==1.23.3 scipy==1.9.2 scikit-rf==0.24.1
But, it succeeded!
So, I continued on with: tox -e py38. (Note the missing -r option.):
$ tox -e py38
{snip}
py38 create: C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38
py38 installcondadeps: scikit-rf, numpy, scipy
py38 installdeps: pytest, pytest-xdist, pytest-cov
py38 inst: C:\Users\capnf\Documents\GitHub\PyBERT\.tox\.tmp\package\1\PyBERT-4.0.0.tar.gz

Note the missing --no-deps in the last command above; significant?
I'm finding that my conda-installed numpy package is still getting overwritten:
$ conda activate .tox/py38/
(C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38)
capnf@DESKTOP-G84ND7C MINGW64 ~/Documents/GitHub/PyBERT (add-tests)
$ conda list numpy
# packages in environment at C:\Users\capnf\Documents\GitHub\PyBERT\.tox\py38:
#
# Name                    Version                   Build  Channel
numpy                     1.23.3                   pypi_0    pypi

And I'm wondering if it's the installation of the PyBERT package that is causing the overwrite.
(Note the missing --no-deps option in the py38 inst: C:\...\PyBERT...tar.gz command above.)

If you need to use conda anyway, then you may use the very same version pinning in tox.ini as they appear in pyproject.toml.

That worked!
Thank you. :)


BeaconNode <--> ValidatorClient API - Messages

ETH2.0 Beacon Node & Validator Client RPC Proposal
Outline
This issue proposes a minimal communications specification between a beacon node and validator client, targeting phase 0 of the Eth2.0 specification. The protocol is designed to be a simple local communications interface, permitting two separate binaries to communicate.
This specification is intended to describe communication abstractly, without choosing any particular protocol. The protocol used (e.g. gRPC/JSON-RPC) is discussed in a separate issue: #1012.
This issue follows on from a discussion during the Client Architecture session at the Sydney Implementers meeting. This also follow from the Client Architecture Roundtable in Prague.
There is an editable version of this document, here: https://hackmd.io/r7D61hs4RWKm8nz_O2iinQ
Background
The beacon node maintains the state of the beacon chain by communicating with other beacon nodes in the Ethereum Serenity network. Conceptually, it does not maintain keypairs that participate with the beacon chain.
The validator client is conceptually a separate entity which utilises private keys to perform validator related tasks on the beacon chain, which we call validator "duties". This includes the production of beacon blocks and signing of attestations.
Since it is recommended to separate these concerns in the client implementations, it is necessary for us to clearly define the communication between them.
The goal of this specification is to promote interoperability between beacon nodes and validator clients derived from different projects. For example, the validator client from Lighthouse, could communicate with a running instance of the beacon node from Prysm.
This proposal has been adapted from the Lighthouse gRPC protocol specification.
There is also another WIP proposal for a Minimum Validator Interface, which describes additional functions possibly necessary for phase 1 and beyond.
Specification
Entities
The following are the two entities that participate in this protocol:

BeaconNode:
A beacon node instance, run with a --rpc flag to enable the RPC interface. Runs stand-alone.

ValidatorClient:
A validator client instance, which must connect to at least one instance of BeaconNode.

Endpoints
This section summarises API endpoints which are published by an instance of BeaconNode, for the exclusive use of ValidatorClient implementations.
This proposal is a minimum set of messages necessary to enable effective communication, without any extra features. Anything extra is beyond the scope of this document.
Summary Table

Name
Type
Parameters
Returns

get_client_version
GET
N/A
client_version

get_genesis_time
GET
N/A
genesis_time

get_syncing_status
GET
N/A
syncing_status

get_duties
GET
validator_pubkeys
syncing_status, current_version, [ValidatorDuty]

produce_block
GET
slot, randao_reveal
beacon_block

publish_block
POST
beacon_block
N/A

produce_attestation
GET
slot, shard
indexed_attestation

publish_attestation
POST
indexed_attestation
N/A

Status Codes
For each of these endpoints the underlying transport protocol should provide status codes. Assuming this will be based on HTTP, one of the following standard status codes will always be included as part of a response:

Code
Meaning

200
The API call succeeded.

40X
The request was malformed.

500
The BeaconNode cannot complete the request due to an internal error.

503
The BeaconNode is currently syncing, try again later. A call can be made to get_syncing_status to in order to find out how much has been synchronised.

get_client_version
Requests that the BeaconNode identify information about its implementation in a format similar to a HTTP User-Agent field.

Parameters: N/A
Returns:

Name
Type
Description

client_version
bytes32
An ASCII-encoded hex string which uniquely defines the implementation of the BeaconNode and its current software version.

Note: Unlike most other endpoints, get_client_version does not return an error 503 while the BeaconNode is syncing, but instead returns status code 200.
get_genesis_time
Requests the genesis_time parameter from the BeaconNode, which should be consistent across all BeaconNodes that follow the same beacon chain.

Parameters: N/A
Returns:

Name
Type
Description

genesis_time
uint64
The genesis_time, which is a fairly static configuration option for the BeaconNode.

Note: Unlike most other endpoints, get_genesis_time does not return an error 503 while the BeaconNode is syncing, but instead returns status code 200.
get_syncing_status
Requests the BeaconNode to describe if it's currently syncing or not, and if it is, what block it is up to. This is modelled after the Eth1.0 JSON-RPC eth_syncing call.

Parameters: N/A
Returns:

Name
Type
Description

syncing
false OR SyncingStatus
Either false if the node is not syncing, or a SyncingStatus object if it is.

Note: Unlike most other endpoints, get_syncing_status does not return an error 503 while the BeaconNode is syncing, but instead returns status code 200 with the SyncingStatus object.
get_duties
Requests the BeaconNode to provide a set of “duties”, which are actions that should be performed by ValidatorClients. This API call should be polled at every slot, to ensure that any chain reorganisations are catered for, and to ensure that the currently connected BeaconNode is properly synchronised.

Parameters:

Name
Type
Description

validator_pubkeys
[bytes48]
A list of unique validator public keys, where each item is a 0x encoded hex string.

Returns:

Name
Type
Description

current_version
bytes4
The current_version, as described by the current Fork.

validator_duties
[ValidatorDuty]
A list where each item is a custom ValidatorDuty object.

produce_block
Requests a BeaconNode to produce a valid block, which can then be signed by a ValidatorClient.

Parameters:

Name
Type
Description

slot
uint64
The slot for which the block should be proposed.

randao_reveal
bytes
The ValidatorClient's randao reveal value.

Returns:

Name
Type
Description

beacon_block
BeaconBlock
A proposed BeaconBlock object, but with the signature field left blank.

publish_block
Instructs the BeaconNode to publish a newly signed beacon block to the beacon network, to be included in the beacon chain.

Parameters:

Name
Type
Description

beacon_block
BeaconBlock
The BeaconBlock object, as sent from the BeaconNode originally, but now with the signature field completed.

Returns: N/A

produce_attestation
Requests that the BeaconNode produce an IndexedAttestation, with a blank signature field, which the ValidatorClient will then sign.

Parameters:

Name
Type
Description

slot
uint64
The slot for which the attestation should be proposed.

shard
uint64
The shard number for which the attestation is to be proposed.

Returns:

Name
Type
Description

indexed_attestation
IndexedAttestation
An IndexedAttestation structure with the signature field left blank.

publish_attestation
Instructs the BeaconNode to publish a newly signed IndexedAttestation object, to be incorporated into the beacon chain.

Parameters:

Name
Type
Description

indexed_attestation
IndexedAttestation
An IndexedAttestation structure, as originally provided by the BeaconNode, but now with the signature field completed.

Returns: N/A

Data Structures
Two new data objects are proposed for the sake of implementation, and several other data objects from the Eth2.0 specs are referenced.
The bytes data types are encoded hex strings, with 0x preceeding them. uint64 are decimal encoded integers, and None may be null, which is distinct from 0.
ValidatorDuty
{

    # The validator's public key, uniquely identifying them
    'validator_pubkey': 'bytes48',
    # The index of the validator in the committee
    'committee_index': 'uint64',
    # The slot at which the validator must attest.
    'attestation_slot': 'uint64',
    # The shard in which the validator must attest
    'attestation_shard': 'uint64',
    # The slot in which a validator must propose a block. This field can also be None.
    'block_production_slot': 'uint64' or None
}

SyncingStatus
As described by the Eth1.0 JSON-RPC.:
{
    # The block at which syncing started (will only be reset, after the sync reached his head)
    'startingBlock': 'uint64',
    # The current block
    'currentBlock': 'uint64',
    # The estimated highest block, or current target block number
    'highestBlock': 'uint64'
}

Fork
As described by Fork in the Eth2.0 specs.
BeaconBlock
As described by BeaconBlock in the Eth2.0 specs.
IndexedAttestation
As described by IndexedAttestation in the Eth2.0 specs.
Optional Extras
Endpoint: get_fork
Requests the BeaconNode to provide which fork version it is currently on.

Parameters: N/A
Returns:

Name
Type
Description

fork
Fork
Provides the current version information for the fork which the BeaconNode is currently following.

chain_id
uint64
Sometimes called the network id, this number discerns the active chain for the BeaconNode. Analagous to Eth1.0 JSON-RPC net_version.

This is great!
For get_duties i would add that array order must be maintained.

another option is that we define the interfaces such that the beacon node returns everything the validator client provides in the request, such that the response is a strict superset of the request.
this is kind of the route that (afaiui) graphQL takes, where a server will "fill in the blanks" for a given client.
i would argue this is helpful for a few reasons (probably others):

debuggability -- the complete packet of info can be in one place, rather than having to manually thread a request and response message
safety -- this came to mind after reading: https://github.com/ethereum/eth2.0-specs/issues/1011#issuecomment-488041552; a payload of "duties" lacking the full context is dangerous imo. as a validator, i should know for which pubkeys i should perform which duties... the current suggestion assumes i'll keep an ordered list somewhere that i can check against which seems error prone in the case that (i) nodes cycle, (ii) i have a bug in my list-checking code, etc.
backwards compatibility -- the fewer constraints we place on the API today, the less change will be necessary in the future

i think this notion of safety is pretty important so i would extend the design principle across every API (and really this stands for any RPC we will define for the whole endeavor) -- the only downside is the additional communication overhead but i don't see it being that major

Can you put this issue into a PR? It would make it much easier to review and add comments directly to this spec. Great work!

@ralexstokes I think this is probably better to ask existing teams from eth1.x what would make sense (ethers.js, web3.js,... Etc)
I'll forward this off to my tooling group and see if they have Any input.

Can you put this issue into a PR? It would make it much easier to review and add comments directly to this spec. Great work!

Thanks! I was originally going to do it as a PR, and happy to do so, I'm just not sure of a sensible place for the doc to reside. Open to suggestion!

Perhaps, you can place it under specs/validator?

Are we sure we want to be using indexedAttestations? rather Attestation or AttestationData

I think the get_duties call could/should be split out into proposer assignment and committee assignment.
It seems like the committee only needs to be checked once per epoch (and can be looked up one epoch beforehand), whereas the block production assignment must be checked every slot.
I'm thinking something that mirrors the two functions here: https://github.com/ethereum/eth2.0-specs/blob/dev/specs/validator/0_beacon-chain-validator.md#validator-assignments

How about introducing namespacing for methods (similar to eth1). Since in the future there will be a lot more methods exposed from beacon node (for block explorers for example) and it will be hard to differentiate purpose.
Some proposal would be:

beacon_get_client_version
beacon_get_genesis_time
beacon_get_syncing_status
validator_get_duties
validator_produce_block
validator_publish_block
validator_produce_attestation
validator_publish_attestation

produceBlock is a very high level method that incorporates many component pieces.
Does anyone have thoughts about exposing a lower level interface that allows the validator to create a block itself?
Likewise with produceAttestation and letting the validator create an Attestation according to the steps here: https://github.com/ethereum/eth2.0-specs/blob/dev/specs/validator/0_beacon-chain-validator.md#construct-attestation

Regarding the actual message format, I'd suggest only little things, like keeping consistent datatypes - so get syncing status would be more useful if it just returned the syncing status, which could include the info that it was not syncing, or simply return null. Returning false or object makes implementation a bit more complicated as you have to check if you get Bool or Object.
Also - I am not up to speed on the actual Eth 2.0 stuff  but are there cases for PUT as well as POST here?
Finally, (referring to the other issue on the actual protocol), I'd suggest a  REST-like structure  of the messages and roles (eventually one node may serve multiple APIs not just this beacon one):
https://beaconapi20190506111547.azurewebsites.net/

Are we sure we want to be using indexedAttestations? rather Attestation or AttestationData
@GregTheGreek - I think this was resolved on Gitter. IndexedAttestation is easiest because it also includes the size of the committee, which is necessary for formulating the custody bits.

It could also be possible for the BeaconNode to send AttestationData, then the ValidatorClient return IndexedAttestation, however to keep things simple and symmetric, we chose to just keep it is as an IndexedAttestation in both directions.

I think the get_duties call could/should be split out into proposer assignment and committee assignment.

@wemeetagain - I think our plan is to check both pieces of information every slot, since both the committee and block production could theoretically change at any point due to forks.

produce_block is a very high level method that incorporates many component pieces.
Does anyone have thoughts about exposing a lower level interface that allows the validator to create a block itself?

We decided to keep the API minimal, and keep functionality in the ValidatorClient only to what is absolutely necessary. Your proposal to have lower level interfaces which allow the ValidatorClient to create blocks itself requires a great deal more functionality be moved into the ValidatorClient. So that we don't need to have all the heavy logic in the ValidatorClient, such as committee selection, etc., we decided to keep that all in the BeaconNode, and have it produce the block. That way the ValidatorClient only needs to check that it won't be slashed, then sign and return the data.

How about introducing namespacing for methods (similar to eth1)?

@mpetrunic - This is a fantastic idea. I will introduce namespacing in my next revision of this API proposal.

Regarding the actual message format, I'd suggest only little things, like keeping consistent datatypes - so get syncing status would be more useful if it just returned the syncing status, which could include the info that it was not syncing, or simply return null. Returning false or object makes implementation a bit more complicated as you have to check if you get Bool or Object.

@FrankSzendzielarz - This is a good point, I will keep the data types of the return values consistent in my next revision of the proposal.
I also agree that HTTP-REST is a better choice than JSON-RPC, which is discussed in more detail in #1012.

Perhaps, you can place it under specs/validator?

Good idea @Mikerah.
@djrtwo - Do you think it makes sense to submit a PR with a Markdown RFC in specs/validator?
If so, I'll go ahead and merge the comments/discussions from this thread and #1012 into that.

How about introducing namespacing for methods (similar to eth1)?

@mpetrunic - This is a fantastic idea. I will introduce namespacing in my next revision of this API proposal.

If we roll with REST-HTTP (#1012) we can achieve this with urls (e.g., /beacon/foo, /validator/bar).

@spble "Do you think it makes sense to submit a PR with a Markdown RFC in specs/validator?
If so, I'll go ahead and merge the comments/discussions from this thread and #1012 into that."
Let me know but if you want I can fine tune the swagger and give you the auto generated MD from the swagger codegen. Have a look at the docs folder in the golang zip in #1012 if it suits.

@mpetrunic eg https://beaconapi20190506111547.azurewebsites.net/swagger/ui/index 😀

@mpetrunic eg https://beaconapi20190506111547.azurewebsites.net/swagger/ui/index

I would pull validator endpoints under root /validator (remove beacon prefix). Also block and attestation endpoints should go under validator root. Mainly because those routes are not going to be used by general public (etherjs, block explorers etc) so there is no need for people to scroll trough them.

@mpetrunic I can change that to reflect what is agreed on here. I am not familiar with the actual spec but it strikes me that for at least testnets you will have single implementations running as both Beacon and Validator - in which case I think the above API is the api the Beacon would be offering. If this is the case , I'd say the beacon prefix should remain in place.

@FrankSzendzielarz Let me give you some example of what I meant:
GET /beacon/Block - should return latest(head) beacon block
GET /validator/Block - should produce block without signature
Currently only these methods belong in beacon root :
GET /beacon/client/version
GET /beacon/client/genesistime
GET /beacon/client/syncstatus

@mpetrunic Ah I see. Yes that makes sense.

@mpetrunic good point! I have two potentially interesting thoughts around this:
Searching for pubkeys in the validator registry
Lighthouse also found this O(n) search problem whilst bench-marking deposits processing at large numbers of validators (300k, 4M). When processing a Deposit, you need to do the same search through the validator_registry to see if the validator already exists. We found this was massively blowing-up our block processing times so we ended up including a public key cache with our BeaconState.
As a result, we have a map hanging around to do O(1) lookups of pubkey -> validator index which suits this purpose perfectly.
ID'ing validators via pubkey vs. validator index
There is an argument that we could use the validator_index as a canonical reference to a specific validator, but I'm a little cautious of it because it seems like we might face edge-cases or design decisions that break the invariant that it's impossible for the same validator_index to point to a different pubkey.
Given that a pubkey is a really solid unique-ID for a validator, I'm tempted to rely upon it. IIRC @djrtwo was leaning towards validator_index so maybe he'd like to throw a hat in the ring.
Of course, I'm keen to hear other's thoughts too.

Since consensus in #1012 was to use a REST API, I have written up a new proposal using the OpenAPI specification. I have tried to incorporate all the suggestions in this thread, though the identification of validators via pubkey vs index remains an open question; I have left it as pubkey for now.
I've opened a PR #1069 which contains the proposed spec, so I will close this issue for now and we can discuss/refine the spec further on the PR.
A 'live' version of the API spec can be viewed on SwaggerHub.


undefined blog posts hrefs on page load

When the page loads, blog posts and categories will have their a hrefs set to /undefined until posts have been loaded. When using a SEO analyzer for example that will trigger a 404 error and as a result a lower SEO score.

fixed with this commit: https://github.com/danielkellyio/awake-template/pull/28/commits/73ba59c0340dbffe2a0b637f7705b3755fb324f3
let me know if you have any more issues. Thanks!