Replacing current working directory in stack trace message not always working as intended.

I had the following test fail when running npm test in a docker container where I had mounting the mocha source at /local.
https://github.com/mochajs/mocha/blob/master/test/unit/runner.spec.js#L406
The issue is here.
https://github.com/mochajs/mocha/blob/1bb6b3977a482c144a61d68ea2e499b22a7db01b/lib/utils.js#L600
The replace call, causes '/usr/local/dev' to be changed to '/usrdev/, and the string comparison fails in the assert.
I imagine you would have to do a fancier regex replacement to get this to work correctly. In practice this might not be a huge issue since users tend to be in /home/username/path which should be reasonably unique.
However, I can imagine a situation where some files being stored at /tmp/<random_string>/home/username/path/filename or a similar location would occur in a stack trace message and be replaced to /tmp/<random_string>/filename.

Hmm... I can't think of a reason other than temporary files to be running JS outside the nice little project-local stack managed by NPM, and I am having a hard time imagining a temporary file reusing the project's path (wherever the project is) inside the temporary files directory, but...
If there's a standard way for a JS regex built from strings to escape one particular part of the regex, we'd just need to escape cwd that way and then prepend "^" to it, I believe, so that seems like it would be easy enough provided we aren't writing custom regex voodoo.

Followup -- I don't know about a standard way, but elsewhere in Mocha (e.g. the fgrep function) we use the var escapeRe = require('escape-string-regexp'); package, like so: new RegExp(escapeRe(string)) -- presumably line = line.replace(escapeRe(cwd), ''); would do? (It'd be nice to get an integration test for the filepath formatting in this type of case, and thereby confirm that the fix works.)

closed via #3244


Oauth Bearer Token Authorization

The authentitaion should be wider than the PRIVATE_TOKEN
With Oauth we should also be able to send a Bearer Token
https://docs.gitlab.com/ee/api/oauth2.html#access-gitlab-api-with-access-token
For what i can see the change is on private GitLabHttpFacade:
https://github.com/nmklotas/GitLabApiClient/blob/bef459a658c3a7d9a84ec6a0be66880cc23b4c2d/src/GitLabApiClient/Internal/Http/GitLabHttpFacade.cs#L12
in this moment:
https://github.com/nmklotas/GitLabApiClient/blob/bef459a658c3a7d9a84ec6a0be66880cc23b4c2d/src/GitLabApiClient/Internal/Http/GitLabHttpFacade.cs#L26
The request is made with the header Key Authorization and value: Bearer {Token}

I added support for bearer token and even added support for requesting an API token with username and password.


Fix docs

By analyzing the blame information on this pull request, we identified @nathanboktae and @failpunk to be potential reviewers

Fixes #147


deduplicate references lists in tsbuildinfo

When referencedMap or exportedModulesMap contain duplicates, they are replaced with an index of the deduplicated value in referencedMapLists resp. exportedModulesMapLists.
This is actually quite common as .d.ts and .ts file often share references.
This saves a bit storage, makes restoring faster and due to using references to a shared list (since immutable) this also saves a bit of memory.
Finding duplicates during storing can be expensive, so we make use of the equal identity when this was restored from tsbuildinfo. Otherwise we create a Map by list length to avoid checking too many lists.

[ ] There is an associated issue in the Backlog milestone (required)
[x] Code is up-to-date with the master branch
[x] You've successfully run gulp runtests locally
[x] There are new or updated unit tests validating the change

Some statistics:
For my project this reduces the tsbuildinfo size from 14.9 MB to 2.2MB.

btw. is it necessary to emit a formatted json (JSON.stringify(data, null, 2)) instead of just pure json (JSON.stringify(data))? That would save nearly the half of the size...

@sokra Created PR #43155 based off of this one with simplification and additional optimization of fileinfos, semantic diagnostic and your suggestion of getting rid of spaces in tsbuildinfo.
Bot should post a build on that PR. Can you check if this works for your scenario.
Thanks


Main page does not display properly

Issue Type

[x] Bug
[ ] Enhancement

Description
Operating System
Please include the version number (ex: Ubuntu 16.04)
Install

[x] setup.bash
[ ] docker

DefectDojo Version
1.5.2
Steps to Reproduce
installation using setup.bash script and access to the login page.
Screenshots

Console Logs

There was a change in a version of a static asset. Copy this file into components/package.json and then re-run yarn by executing the following commands.

In the root of your dojo directory
cd components && yarn && cd ..
python manage.py collectstatic --noinput

Thanks, it solved the issue !


Creating new libraries, automatically create the directory.

Is your feature request related to a problem? Please describe.
New users using manyfold, shouldn't need to know the directory path.  And it should automatically create the library folder.  Remembering the base library path is hard to do, and is not necessary.
Describe the solution you'd like

Add a setting for the base folder path (it should know this already (/libraries)
When creating a library, snake case the name, and create the folder automatically, don't show an option (or if you do, put it under advanced)

Good idea 👍🏻


Allow for running ad-hoc commands

As discussed briefly on here:
https://twitter.com/FlywayDb/status/654258076158140416
The sql-maven-plugin has the capability of choosing between running:

External files
Ad-hoc SQL statements

The latter can be very useful in situations where I want to run a specific command after running a couple of external files, and for various reasons, I don't want to put that command in those files. For example, when using HSQLDB, which maintains a database lock per class loader, which prevents subsequent Maven plugins (e.g. that of jOOQ) to access the database that is created by sql-maven-plugin. An example can be seen here:
http://stackoverflow.com/a/33123478/521799
Now, with Flyway, I currently don't see such a workaround, as can be seen in this Stack Overflow question:
http://stackoverflow.com/q/28402745/521799
I think it would be interesting if it were possible to define "ad-hoc migrations" in Flyway in addition to the existing file-based ones. Flyway could generate a hash code from the ad-hoc migration statement(s) as a migration "script" identifier.
What do you think?

At this point I feel this would be a distraction from the core premise of Flyway. I'll keep this open for now and see how my thoughts evolve on this.

What is the core premise of Flyway? :)

Migrating your schema with ease. An essential part of CD and relational schema evolution. In fact one could almost argue this is the opposite of executing ad-hoc statements :-)
In the case of that SO question the solution is probably to append shutdown=true to the JDBC URL (http://hsqldb.org/doc/guide/ch01.html#N101DB).

Closing as I really don't see this as a goal for Flyway at this point.

Fair enough.


[webinterface] fix version number display

I have to change the way the version is displayed in the webinterface,
because the component is bundled, but will be updated standalone.
e.g. Server Stack v0.8.7 - Webinterface v1.0.0

[x] display version of the stack (based on installer)
[x] display version of the webinterface

[x] add WEBINTERFACE_VERSION placeholder into bootstrap.php
[x] insert TRAVIS_TAG into bootstrap.php

WTF

https://github.com/WPN-XM/webinterface/pull/19/commits/839802a6cabb050c305760e718fa35baefb3d51c
https://travis-ci.org/WPN-XM/webinterface/jobs/132304937#L820


Docker runs inside of vagrant box is failing on docker rate limiting.

Current behaviour
Tests are failing since docker images can not be pulled from docker hub
Expected behaviour
Pulls from docker hub should be successful.
How to reproduce?
Suggestion(s)/solution(s) [Optional]
Checklist (after created issue)

[x] Added label(s)
[ ] Added to project
[x] Added to milestone

After a lot of failing on release procedures; this is finally fixed. The GitHub action docker hub auth is transfered to the running vagrant box while testing


Feature: Support Marathon application api query filters

Do you want to request a feature or report a bug?

Feature
What did you expect to see?

Currently, the Mrathon provider fetches all the application and later performs filtering via constraints.
https://github.com/traefik/traefik/blob/fc7ec1790563ebb4a5fc1544033fb3762fd6d321/pkg/provider/marathon/marathon.go#L212-L219
I have a use cause of hundreds of independent traefik instances querying a single Mesos/Marathon cluster when each traefik instance filters specific applications using constraints.
Because traefik always fetches all the applications it generates large stress on the marathon API (when performed from hundreds of traefik instances).
I would like traefik to support arbitrary query parameters override.
For example:
I would like to filter applications with user:dan label and /us-east/database/memsql id.
[providers.marathon]
  queryParametersOverride = "embed=apps.task&embed=apps.deployments&apps.readiness&label=user==dan&id=/us-east/database/memsql"

If I will get A-OK, I will implement it and open a PR.

Hello @genadipost and thanks for your interest in Traefik,
Feel free to implement this feature and raise a Pull Request 😄
Here are some docs:

Building and Testing Traefik: https://doc.traefik.io/traefik/contributing/building-testing/
Contributors guide: https://github.com/traefik/contributors-guide

Hello @genadipost and thanks for your interest in Traefik,
Feel free to implement this feature and raise a Pull Request 😄
Here are some docs:

Building and Testing Traefik: https://doc.traefik.io/traefik/contributing/building-testing/
Contributors guide: https://github.com/traefik/contributors-guide

Hey @genadipost,
Thanks for building the PR.  Upon Design review, we realized that this feature would not be used by a large enough segment of our users.  Because of this, we will not go forward with this feature.
Thanks for working with us and for your patience.


Distributed Cache

Utilizes an appropriate caching strategy to cache translated data based on frequency and perhaps other parameters
Unit Tests

This is fully implemented as a cache, but could be brought back from the dead if we would prefer to use Memcached later down the road.


Update imagery documentation

https://github.com/CityOfNewYork/nyc-geo-metadata/blob/main/Metadata/Metadata_AerialImagery.md

Last Update: 2018
Metadata: 12/20/2018

Update through 2022.  2022 is available as a service from ArcGIS Online.  I am unsure if it will be loaded to NYC Open data.

https://github.com/CityOfNewYork/nyc-geo-metadata/commit/009b8d47036f2b42dc24c883966e1097be6c840f


Confused by shipping method countries

By default, the table seems to say "Rest of the world". I'm not sure what this means. If I edit my shipping method and I don't check "Products ship internationally", then I would expect to only deliver in my country. I haven't specified what my country is, and I definitely don't want to restrict my shipments to the "rest of the world".

Resolved by #286


Quick fix incorrectly showing "change spelling" instead of "Add missing imports"

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: Latest.
OS Version: Windows 11

Steps to Reproduce:

In angular, go to any module that you can test this.
Note the Declarations section you will have there Components. Ideally try to find a component that starts with the same name than other components like if you have "Package1Component" and "Package2Component", this will do the trick.
Search at the top of your module for the Import for any component you want.
Now delete the import entirely, so it causes an error.
Go back again to the declarations, in the component that is currently failing, and press "control+dot" for a fix.

expected:

The quick fix should be "Include missing imports"

actual:

The quick fix shows "Change spelling", when the Component really exists, and the spelling is perfect.
In my example about "PackageComponent", it will try to change spelling to "Package1Component" when the "Package2Component" exists.

See image as example:

Please share a minimal example project which demonstrates the issue


(XAImpl, Shell): add loadTransaction feature.

Codecov Report

Merging #122 (17ca7d2) into release-1.0.0 (709d8a9) will decrease coverage by 0.12%.
The diff coverage is 0.00%.

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


Internet-header add logged in to documentation for testing

At the moment there is no easy way to test the internet-headers in a logged in state.
My issue #2097 is currently blocked because I cant test the effects of a potential fix in the current state.

@gfellerph, improve description

Closing as out of scope.


Internal error, backward sync completed but failed to import finalized block

execution_1                  | Setting logging level to INFO
execution_1                  | 2023-02-04 19:54:23.830+00:00 | main | INFO  | Besu | Starting Besu
execution_1                  | 2023-02-04 19:54:24.516+00:00 | main | WARN  | Besu | --graphql-http-host has been ignored because --graphql-http-enabled was not defined on the command line.
execution_1                  | 2023-02-04 19:54:24.693+00:00 | main | INFO  | Besu |
execution_1                  | ####################################################################################################
execution_1                  | #                                                                                #
execution_1                  | # Besu 23.1.0-dev-e7150102                                                                         #
execution_1                  | #                                                                                #
execution_1                  | # Configuration:                                                                                #
execution_1                  | # Network: Mainnet                                                                                #
execution_1                  | # Network Id: 1                                                                                #
execution_1                  | # Data storage: Bonsai                                                                             #
execution_1                  | # Sync mode: Snap                                                                                #
execution_1                  | # RPC HTTP APIs: WEB3,ETH,NET                                                                      #
execution_1                  | # RPC HTTP port: 8545                                                                              #
execution_1                  | # Engine APIs: ENGINE,ETH                                                                          #
execution_1                  | # Engine port: 8551                                                                                #
execution_1                  | #                                                                                #
execution_1                  | # Host:                                                                                #
execution_1                  | # Java: openjdk-java-17                                                                            #
execution_1                  | # Maximum heap size: 64.00 GB                                                                      #
execution_1                  | # OS: linux-x86_64                                                                                #
execution_1                  | # glibc: 2.31                                                                                #
execution_1                  | # Total memory: 503.87 GB                                                                          #
execution_1                  | # CPU cores: 80                                                                                #
execution_1                  | #                                                                                #
execution_1                  | ####################################################################################################
execution_1                  | 2023-02-04 19:54:24.694+00:00 | main | INFO  | Besu | Connecting to 0 static nodes.
execution_1                  | 2023-02-04 19:54:24.694+00:00 | main | INFO  | Besu | Security Module: localfile
execution_1                  | 2023-02-04 19:54:24.756+00:00 | main | INFO  | Besu | Using the native implementation of alt bn128
execution_1                  | 2023-02-04 19:54:24.808+00:00 | main | INFO  | Besu | Using the native implementation of modexp
execution_1                  | 2023-02-04 19:54:24.808+00:00 | main | INFO  | Besu | Using the native implementation of the signature algorithm
execution_1                  | 2023-02-04 19:54:24.814+00:00 | main | INFO  | Besu | Using the native implementation of the blake2bf algorithm
execution_1                  | 2023-02-04 19:54:24.840+00:00 | main | INFO  | DatabaseMetadata | Lookup database metadata file in data directory: /var/lib/besu
execution_1                  | 2023-02-04 19:54:24.910+00:00 | main | INFO  | RocksDBKeyValueStorageFactory | Existing database detected at /var/lib/besu. Version 2
execution_1                  | 2023-02-04 19:54:30.154+00:00 | main | INFO  | KeyPairUtil | Loaded public key 0xba5cb5928621f5ef140f8182dde0c6f0c0447562b2b4d7763b72da5c9ce3df41fd872a26687466e7b711ef53d74526bf724b12fe6217504a76268d815c951cd0 from /var/lib/besu/key
execution_1                  | 2023-02-04 19:54:30.353+00:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: [Frontier: 0, Homestead: 1150000, DaoRecoveryInit: 1920000, DaoRecoveryTransition: 1920001, Homestead: 1920010, TangerineWhistle: 2463000, SpuriousDragon: 2675000, Byzantium: 4370000, Petersburg: 7280000, Istanbul: 9069000, MuirGlacier: 9200000, Berlin: 12244000, London: 12965000, ArrowGlacier: 13773000, GrayGlacier: 15050000]
execution_1                  | 2023-02-04 19:54:30.392+00:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: [Frontier: 0, Homestead: 1150000, DaoRecoveryInit: 1920000, DaoRecoveryTransition: 1920001, Homestead: 1920010, TangerineWhistle: 2463000, SpuriousDragon: 2675000, Byzantium: 4370000, Petersburg: 7280000, Istanbul: 9069000, MuirGlacier: 9200000, Berlin: 12244000, London: 12965000, ArrowGlacier: 13773000, GrayGlacier: 15050000]
execution_1                  | 2023-02-04 19:54:30.401+00:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: []
execution_1                  | 2023-02-04 19:54:31.232+00:00 | main | INFO  | TransactionPoolFactory | Enabling transaction pool
execution_1                  | 2023-02-04 19:54:31.233+00:00 | main | INFO  | TransactionPoolFactory | Disabling transaction handling during initial sync
execution_1                  | 2023-02-04 19:54:31.236+00:00 | main | INFO  | EthPeers | Updating the default best peer comparator
execution_1                  | 2023-02-04 19:54:31.260+00:00 | main | INFO  | BesuControllerBuilder | TTD difficulty is present, creating initial sync for PoS
execution_1                  | 2023-02-04 19:54:31.276+00:00 | main | INFO  | SnapDownloaderFactory | Snap sync was requested, but cannot be enabled because the local blockchain is not empty.
execution_1                  | 2023-02-04 19:54:31.278+00:00 | main | INFO  | TransitionBesuControllerBuilder | TTD present, creating DefaultSynchronizer that stops propagating after finalization
execution_1                  | 2023-02-04 19:54:31.308+00:00 | main | INFO  | RunnerBuilder | Detecting NAT service.
execution_1                  | 2023-02-04 19:54:31.474+00:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: []
execution_1                  | 2023-02-04 19:54:31.537+00:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: []
execution_1                  | 2023-02-04 19:54:31.768+00:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: []
execution_1                  | 2023-02-04 19:54:31.785+00:00 | main | INFO  | Runner | Starting external services ...
execution_1                  | 2023-02-04 19:54:31.786+00:00 | main | INFO  | MetricsHttpService | Starting metrics http service on <IP_ADDRESS>:6060
execution_1                  | 2023-02-04 19:54:31.889+00:00 | vert.x-eventloop-thread-1 | INFO  | MetricsHttpService | Metrics service started and listening on <IP_ADDRESS>:6060
execution_1                  | 2023-02-04 19:54:31.889+00:00 | main | INFO  | JsonRpcHttpService | Starting JSON-RPC service on <IP_ADDRESS>:8545
execution_1                  | 2023-02-04 19:54:31.905+00:00 | vert.x-eventloop-thread-1 | INFO  | JsonRpcHttpService | JSON-RPC service started and listening on <IP_ADDRESS>:8545
execution_1                  | 2023-02-04 19:54:31.905+00:00 | main | INFO  | EngineJsonRpcService | Starting JSON-RPC service on <IP_ADDRESS>:8551
execution_1                  | 2023-02-04 19:54:31.911+00:00 | vert.x-eventloop-thread-1 | INFO  | EngineJsonRpcService | JSON-RPC service started and listening on <IP_ADDRESS>:8551
execution_1                  | 2023-02-04 19:54:31.912+00:00 | main | INFO  | WebSocketService | Starting Websocket service on <IP_ADDRESS>:8546
execution_1                  | 2023-02-04 19:54:31.915+00:00 | vert.x-eventloop-thread-1 | INFO  | WebSocketService | Websocket service started and listening on <IP_ADDRESS>:8546
execution_1                  | 2023-02-04 19:54:31.918+00:00 | main | INFO  | AutoTransactionLogBloomCachingService | Starting auto transaction log bloom caching service.
execution_1                  | 2023-02-04 19:54:31.919+00:00 | main | INFO  | LogBloomCacheMetadata | Lookup cache metadata file in data directory: /var/lib/besu/caches
execution_1                  | 2023-02-04 19:54:31.928+00:00 | main | INFO  | Runner | Starting Ethereum main loop ...
execution_1                  | 2023-02-04 19:54:31.928+00:00 | main | INFO  | DockerNatManager | Starting docker NAT manager.
execution_1                  | 2023-02-04 19:54:31.937+00:00 | main | INFO  | NetworkRunner | Starting Network.
execution_1                  | 2023-02-04 19:54:31.940+00:00 | main | INFO  | DefaultP2PNetwork | Starting DNS discovery with URL<EMAIL_ADDRESS>execution_1                  | 2023-02-04 19:54:32.010+00:00 | nioEventLoopGroup-2-1 | INFO  | RlpxAgent | P2P RLPx agent started and listening on /<IP_ADDRESS>:30303.
execution_1                  | 2023-02-04 19:54:32.011+00:00 | main | INFO  | PeerDiscoveryAgent | Starting peer discovery agent on host=<IP_ADDRESS>, port=30303
execution_1                  | 2023-02-04 19:54:32.054+00:00 | vert.x-eventloop-thread-1 | INFO  | VertxPeerDiscoveryAgent | Started peer discovery agent successfully, on effective host=<IP_ADDRESS> and port=30303
execution_1                  | 2023-02-04 19:54:32.055+00:00 | vert.x-eventloop-thread-1 | INFO  | PeerDiscoveryAgent | P2P peer discovery agent started and listening on /<IP_ADDRESS>:30303
execution_1                  | 2023-02-04 19:54:32.108+00:00 | vert.x-eventloop-thread-1 | INFO  | PeerDiscoveryAgent | Writing node record to disk. NodeRecord{seq=83, publicKey=0x02ba5cb5928621f5ef140f8182dde0c6f0c0447562b2b4d7763b72da5c9ce3df41, udpAddress=Optional[/<IP_ADDRESS>:30303], tcpAddress=Optional[/<IP_ADDRESS>:30303], asBase64=-Je4QFFXzeqiZb2EpXqAagdzEjnpXxq90PzI95N7LoRAxSRWULLBJzCv-OzLzUZWApHzyrurQLxpqvSHPyh4a_b9s0hTg2V0aMfGhPCv0OOAgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQK6XLWShiH17xQPgYLd4MbwwER1YrK013Y7ctpcnOPfQYN0Y3CCdl-DdWRwgnZf, nodeId=0x191631e5043602531ea9c04190dd41bbc6f07a2a368438865f39dea4bdce1e33, customFields={tcp=30303, udp=30303, ip=0x7f000001, eth=[[0xf0afd0e3, 0x]], id=V4, secp256k1=0x02ba5cb5928621f5ef140f8182dde0c6f0c0447562b2b4d7763b72da5c9ce3df41}}
execution_1                  | 2023-02-04 19:54:32.181+00:00 | main | INFO  | DefaultP2PNetwork | Enode URL enode://ba5cb5928621f5ef140f8182dde0c6f0c0447562b2b4d7763b72da5c9ce3df41fd872a26687466e7b711ef53d74526bf724b12fe6217504a76268d815c951cd0@<IP_ADDRESS>:30303
execution_1                  | 2023-02-04 19:54:32.183+00:00 | main | INFO  | DefaultP2PNetwork | Node address 0x90dd41bbc6f07a2a368438865f39dea4bdce1e33
execution_1                  | 2023-02-04 19:54:32.189+00:00 | main | INFO  | NetworkRunner | Supported capabilities: [eth/63, eth/64, eth/65, eth/66, eth/67, eth/68], [snap/1]
execution_1                  | 2023-02-04 19:54:32.189+00:00 | main | INFO  | DefaultSynchronizer | Starting synchronizer.
execution_1                  | 2023-02-04 19:54:32.192+00:00 | main | INFO  | TransactionPoolFactory | Enabling transaction handling following initial sync
execution_1                  | 2023-02-04 19:54:32.196+00:00 | main | INFO  | DefaultSynchronizer | Stopping block propagation.
execution_1                  | 2023-02-04 19:54:32.197+00:00 | main | INFO  | DefaultSynchronizer | Stopping the pruner.
execution_1                  | 2023-02-04 19:54:32.198+00:00 | main | INFO  | Runner | Ethereum main loop is up.
execution_1                  | 2023-02-04 19:54:54.203+00:00 | Timer-0 | INFO  | DNSResolver | Resolved 2409 nodes
execution_1                  | 2023-02-04 19:56:06.947+00:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
execution_1                  | 2023-02-04 19:56:06.955+00:00 | vert.x-worker-thread-0 | INFO  | BackwardsSyncAlgorithm | Current backward sync session is done
execution_1                  | 2023-02-04 19:56:08.179+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964
execution_1                  | 2023-02-04 19:56:08.196+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964
execution_1                  | 2023-02-04 19:56:36.760+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964
execution_1                  | 2023-02-04 19:56:38.094+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964
execution_1                  | 2023-02-04 19:56:38.320+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964
execution_1                  | 2023-02-04 19:56:43.985+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964
execution_1                  | 2023-02-04 19:56:49.107+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964
execution_1                  | 2023-02-04 19:57:00.682+00:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xe8f33c4587ca5e19d441139e1d45ba19bb58450b89e1e4e5e21d179b858ab964

I am seeing the same with besu+nimbus
$ journalctl -fu nimbus
Feb 07 05:55:16 hoenir nimbus_beacon_node[63425]: WRN 2023-02-07 05:55:16.191-08:00 Eth1 chain monitoring failure, restarting  topics="eth1" err="No eth1 chain progress for too long"
Feb 07 05:55:21 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:21.202-08:00 Established connection to execution layer  topics="eth1" url=ws://<IP_ADDRESS>:8551
Feb 07 05:55:21 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:21.210-08:00 Starting Eth1 deposit contract monitoring  topics="eth1" contract=0x00000000219ab540356cbb839cbe05303d7705fa
Feb 07 05:55:21 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:21.211-08:00 Waiting for new Eth1 block headers         topics="eth1"
Feb 07 05:55:23 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:23.000-08:00 Slot start                                 topics="beacnde" slot=5746175 epoch=179567 sync=synced/opt peers=3 head=63d1a9ad:5746174 finalized=179565:e24b650c delay=569us275ns
Feb 07 05:55:23 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:23.028-08:00 Slot end                                   topics="beacnde" slot=5746175 nextActionWait=n/a nextAttestationSlot=-1 nextProposalSlot=-1 syncCommitteeDuties=none head=63d1a9ad:5746174
Feb 07 05:55:35 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:35.001-08:00 Slot start                                 topics="beacnde" slot=5746176 epoch=179568 sync=synced/opt peers=1 head=9a03ff29:5746175 finalized=179565:e24b650c delay=1ms180us537ns
Feb 07 05:55:35 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:35.059-08:00 Slot end                                   topics="beacnde" slot=5746176 nextActionWait=n/a nextAttestationSlot=-1 nextProposalSlot=-1 syncCommitteeDuties=none head=9a03ff29:5746175
Feb 07 05:55:47 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:47.001-08:00 Slot start                                 topics="beacnde" slot=5746177 epoch=179568 sync=synced/opt peers=1 head=9a03ff29:5746175 finalized=179565:e24b650c delay=1ms986ns
Feb 07 05:55:47 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:47.012-08:00 Slot end                                   topics="beacnde" slot=5746177 nextActionWait=n/a nextAttestationSlot=-1 nextProposalSlot=-1 syncCommitteeDuties=none head=9a03ff29:5746175
Feb 07 05:55:59 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:59.000-08:00 Slot start                                 topics="beacnde" slot=5746178 epoch=179568 sync=synced/opt peers=1 head=9a03ff29:5746175 finalized=179565:e24b650c delay=369us4ns
Feb 07 05:55:59 hoenir nimbus_beacon_node[63425]: INF 2023-02-07 05:55:59.011-08:00 Slot end                                   topics="beacnde" slot=5746178 nextActionWait=n/a nextAttestationSlot=-1 nextProposalSlot=-1 syncCommitteeDuties=none head=9a03ff29:5746175

$ journalctl -fu besu
Feb 07 05:57:11 hoenir besu[63177]: 2023-02-07 05:57:11.864-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:12 hoenir besu[63177]: 2023-02-07 05:57:12.797-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:24 hoenir besu[63177]: 2023-02-07 05:57:24.460-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:36 hoenir besu[63177]: 2023-02-07 05:57:36.382-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:48 hoenir besu[63177]: 2023-02-07 05:57:48.481-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:58:00 hoenir besu[63177]: 2023-02-07 05:58:00.512-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:58:12 hoenir besu[63177]: 2023-02-07 05:58:12.506-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:58:24 hoenir besu[63177]: 2023-02-07 05:58:24.691-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:58:36 hoenir besu[63177]: 2023-02-07 05:58:36.540-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:58:48 hoenir besu[63177]: 2023-02-07 05:58:48.534-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:59:00 hoenir besu[63177]: 2023-02-07 05:59:00.963-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:59:12 hoenir besu[63177]: 2023-02-07 05:59:12.792-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:11 hoenir besu[63177]: 2023-02-07 05:57:11.864-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:12 hoenir besu[63177]: 2023-02-07 05:57:12.797-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:24 hoenir besu[63177]: 2023-02-07 05:57:24.460-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:36 hoenir besu[63177]: 2023-02-07 05:57:36.382-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
Feb 07 05:57:48 hoenir besu[63177]: 2023-02-07 05:57:48.481-08:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcc22eb80224a603e6be9fa49757f353fccf4f3ccfb5951c2643e07412f42474c
...

Same on Besu 22.10.3

i had to wipe out the database and resync... now i get this error:
16:39:41.505+00:00 | nioEventLoopGroup-3-5 | INFO  | MainnetBlockValidator | Invalid block 16574659 (0x1705627c83ba63c2f36eebc4a9b6f528fdb8da170da86b05f2d88b1b28222998): Optional[Unable to process block because parent world state 0xaafc4f9ce660df414b92bba48eae0129545714962267a5a383c3aac7342f8137 is not available]
execution_1                  | 2023-02-07 16:39:41.712+00:00 | nioEventLoopGroup-3-5 | INFO  | MainnetBlockValidator | Invalid block 16574659 (0x1705627c83ba63c2f36eebc4a9b6f528fdb8da170da86b05f2d88b1b28222998): Optional[Unable to process block because parent world state 0xaafc4f9ce660df414b92bba48eae0129545714962267a5a383c3aac7342f8137 is not available]
execution_1                  | 2023-02-07 16:39:41.917+00:00 | nioEventLoopGroup-3-5 | INFO  | MainnetBlockValidator | Invalid block 16574659 (0x1705627c83ba63c2f36eebc4a9b6f528fdb8da170da86b05f2d88b1b28222998): Optional[Unable to process block because parent world state 0xaafc4f9ce660df414b92bba48eae0129545714962267a5a383c3aac7342f8137 is not available]
execution_1                  | 2023-02-07 16:39:42.135+00:00 | nioEventLoopGroup-3-5 | INFO  | MainnetBlockValidator | Invalid block 16574659 (0x1705627c83ba63c2f36eebc4a9b6f528fdb8da170da86b05f2d88b1b28222998): Optional[Unable to process block because parent world state 0xaafc4f9ce660df414b92bba48eae0129545714962267a5a383c3aac7342f8137 is not available]
execution_1                  | 2023-02-07 16:39:42.339+00:00 | nioEventLoopGroup-3-5 | INFO  | MainnetBlockValidator | Invalid block 16574659 (0x1705627c83ba63c2f36eebc4a9b6f528fdb8da170da86b05f2d88b1b28222998): Optional[Unable to process block because parent world state 0xaafc4f9ce660df414b92bba48eae0129545714962267a5a383c3aac7342f8137 is not available]
execution_1                  | 2023-02-07 16:39:42.545+00:00 | nioEventLoopGroup-3-5 | INFO  | MainnetBlockValidator | Invalid block 16574659 (0x1705627c83ba63c2f36eebc4a9b6f528fdb8da170da86b05f2d88b1b28222998): Optional[Unable to process block because parent world state 0xaafc4f9ce660df414b92bba48eae0129545714962267a5a383c3aac7342f8137 is not available]
^CERROR: Aborting.

hardware specs:

Oracle VM
VM.Standard.E4.Flex
OCPU count: 12
Memory: 32GB

Config:

--network=MAINNET \
--data-storage-format=BONSAI \
--Xbonsai-use-snapshots=false \
--sync-mode=FULL \
--Xplugin-rocksdb-high-spec-enabled=true

How long were you syncing for before this happened?

2.5 months

I haven't set anything related to Java other than to install openjdk-17-jre-headless and run Besu off release binary on an Ubuntu 20.04.5 VM

No metrics

Logs
6daylogs.txt.zip

DEBUG Logs:
today.trimmed.log.zip

More logs as requested. Set logging back to info, then sent this:
curl --retry-delay 50 --retry-connrefused --location \
     --request POST 'http://<IP_ADDRESS>:8545' \
     --header 'Content-Type: application/json' \
     --data-raw '{
    "jsonrpc": "2.0",
    "method": "admin_changeLogLevel",
    "params": [
        "TRACE", [
          "org.hyperledger.besu.ethereum.eth.sync.backwardsync",
          "org.hyperledger.besu.consensus.merge"
        ]
    ],
    "id": 1
}'

This is the resulting logs:
morelogs.txt.zip
Doesn't look super helpful but 🤷♂

Last 1 hour of logs from Besu, Lighthouse, and Teku. Switching to Teku and rebooting seems to have "fixed it"
3ClientLogs.zip

@realsnick @smasher816 @estensen if you're still having this issue, based on quickchase's experience above, you could try switching to teku, letting it sync, then restarting EL.

@realsnick which CL were you using when you got this error?

Resynced from scratch like @realsnick
Lost internet today and changed Wi-Fi while backward syncing was in progress, making it halt.
Restarted and I'm now seeing this error again.
Having to sync another CL seems like a big hacky workaround.
I don't think I have the hardware to run Teku and Besu on the same machine.
Will there be a real fix to this soon?

Is the only option then to do a full resync again?

Having to sync another CL seems like a big hacky workaround.

It is indeed a workaround as we investigate this issue. We are treating this as a besu bug, but it could be a bug that is unique to certain combinations of execution + consensus clients.

Will there be a real fix to this soon?

We are actively looking at this. It's hard to recreate this situation, so any information users can provide is really valuable.

Is the only option then to do a full resync again? @siladu

If you can't try another CL then yes, resync will fix it.
We are also working on ways to repair the state and have some experimental code you could try, but resync would be the easier option if you want to get up and running ASAP

Thanks for looking at it @siladu. I'm just a bit stressed that the db gets corrupted two weeks in a row. I do appreciate the hard work you guys are putting in.
These are the logs from when it happened
2023-02-15 14:17:17.636+01:00 | Timer-0 | WARN  | DNSResolver | I/O exception contacting remote DNS server when resolving all.mainnet.ethdisco.net
java.io.IOException: Timed out while trying to resolve all.mainnet.ethdisco.net./TXT, id=47998
	at org.xbill.DNS.Resolver.send(Resolver.java:170)
	at org.apache.tuweni.discovery.DNSResolver.resolveRecordRaw(DNSResolver.kt:155)
	at org.apache.tuweni.discovery.DNSResolver.resolveRecord(DNSResolver.kt:73)
	at org.apache.tuweni.discovery.DNSResolver.visitTree(DNSResolver.kt:120)
	at org.apache.tuweni.discovery.DNSResolver.visitTree(DNSResolver.kt:111)
	at org.apache.tuweni.discovery.DNSResolver.collectAll(DNSResolver.kt:95)
	at org.apache.tuweni.discovery.DNSTimerTask.run(DNSDaemon.kt:89)
	at java.base/java.util.TimerThread.mainLoop(Timer.java:566)
	at java.base/java.util.TimerThread.run(Timer.java:516)
2023-02-15 14:20:14.518+01:00 | jupnp-114286 | WARN  | SpecificationViolationReporter | UPnP specification violation: Unsupported UDA minor version, ignoring: 1
2023-02-15 14:20:14.584+01:00 | jupnp-114286 | WARN  | UpnpNatManager | Detected multiple WANIPConnection services on network. This may interfere with NAT circumvention.
2023-02-15 14:20:54.344+01:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-02-15 14:20:55.419+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardsSyncAlgorithm | Backward sync target block is 16633306 (0xce7ad592dfd48ab2e37703f522540c7a788c5e7f0c5c40d4c9b0068dbaba2df7)
2023-02-15 14:20:55.927+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 2
2023-02-15 14:20:58.023+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 33.33% completed, imported 1 blocks of at least 3 (current head 16633304, target head 16633306). Peers: 2
2023-02-15 14:21:00.826+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 3 blocks. Peers: 2
2023-02-15 14:21:01.514+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardsSyncAlgorithm | Backward sync target block is 16633369 (0x4709f52b3dad595047689d055c68091e954c8bb2286b384e24769bd8f1628d84)
2023-02-15 14:21:02.343+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 2
2023-02-15 14:21:08.706+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 7.58% completed, imported 5 blocks of at least 66 (current head 16633308, target head 16633369). Peers: 2
2023-02-15 14:21:19.779+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 22.73% completed, imported 15 blocks of at least 66 (current head 16633318, target head 16633369). Peers: 4
2023-02-15 14:21:30.262+01:00 | nioEventLoopGroup-3-4 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 34.85% completed, imported 23 blocks of at least 66 (current head 16633326, target head 16633369). Peers: 2

I switched to my 5 GHz and then it stopped logging for 5 minutes. I then aborted and then I started getting Internal error, backward sync completed but failed to import finalized block
I deleted the log files in the database dir and it managed to resolve the issue without resyncing

@estensen

I'm just a bit stressed that the db gets corrupted two weeks in a row.

It is unfortunate to happen twice in a row and I'm sure annoying. Be assured we will continue to work on stability issues like this as a top priority :)
In addition, we have dramatically improved overall block processing performance and made syncing more robust, the effect being that resyncing from scratch is much less painful when it does have to happen.
There is an upcoming release which is looking like it will be announced this week (I'm a bit reticent to say this as it's been delayed in the past!) so please bear with us and look out for announcements 🙏

Same problem here. After upgrade to Besu 22.10.3 it spams this on restart:
| vertx-blocked-thread-checker | WARN  | BlockedThreadChecker | Thread Thread[vert.x-eventloop-thread-3,5,main] has been blocked for 19520 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
	at app//com.google.common.net.InetAddresses.textToNumericFormatV4(InetAddresses.java:226)
[...]

And after another restart:
| vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x04d25e230dfbf9cc0138f38c53c34b3359eafa4e5dd075a1c4ba16cd79e41316

After another restart it seems to be back to normal.
Not good for my heart health ;P

22.10.3

@Armaver can I just confirm whether you mean upgrade to 22.10.3, or do you mean the recent release: 23.1.0?

Same problem here, twice in one week.

Hi @SgtDinosaur which Besu version and CL are you using?

CL client is Lighthouse.
~/Downloads/besu/build/install/besu/bin/besu --data-path ~/.eth2/besu --p2p-port 23426 --p2p-host "<IP_ADDRESS>" --rpc-http-enabled --host-allowlist "<IP_ADDRESS>" --rpc-http-port 8547 --data-storage-format=BONSAI --engine-jwt-enabled=true --engine-rpc-port 8551 --engine-host-allowlist "<IP_ADDRESS>" --engine-jwt-secret ~/.eth2/jwtsecret --Xplugin-rocksdb-high-spec-enabled --sync-mode=X_CHECKPOINT
2023-03-01 21:16:35.445-05:00 | main | INFO  | Besu | Starting Besu
2023-03-01 21:16:35.719-05:00 | main | INFO  | Besu |
####################################################################################################
#                                                                                #
# Besu 23.1.0                                                                                #
#                                                                                #
# Configuration:                                                                                #
# Network: Mainnet                                                                                #
# Network Id: 1                                                                                #
# Data storage: Bonsai                                                                             #
# Sync mode: Checkpoint                                                                            #
# RPC HTTP APIs: ETH,NET,WEB3                                                                      #
# RPC HTTP port: 8547                                                                              #
# Engine APIs: ENGINE,ETH                                                                          #
# Engine port: 8551                                                                                #
# High spec configuration enabled                                                                  #
#                                                                                #
# Host:                                                                                #
# Java: openjdk-java-17                                                                            #
# Maximum heap size: 15.66 GB                                                                      #
# OS: linux-x86_64                                                                                #
# glibc: 2.35                                                                                #
# Total memory: 62.65 GB                                                                           #
# CPU cores: 16                                                                                #
#                                                                                #
####################################################################################################
2023-03-01 21:16:35.721-05:00 | main | INFO  | Besu | Connecting to 0 static nodes.
2023-03-01 21:16:35.721-05:00 | main | INFO  | Besu | Security Module: localfile
2023-03-01 21:16:35.751-05:00 | main | INFO  | Besu | Using the native implementation of alt bn128
2023-03-01 21:16:35.776-05:00 | main | INFO  | Besu | Using the native implementation of modexp
2023-03-01 21:16:35.776-05:00 | main | INFO  | Besu | Using the native implementation of the signature algorithm
2023-03-01 21:16:35.784-05:00 | main | INFO  | Besu | Using the native implementation of the blake2bf algorithm
2023-03-01 21:16:35.792-05:00 | main | INFO  | DatabaseMetadata | Lookup database metadata file in data directory: /home/seamonkey/.eth2/besu
2023-03-01 21:16:35.817-05:00 | main | INFO  | RocksDBKeyValueStorageFactory | Existing database detected at /home/seamonkey/.eth2/besu. Version 2
2023-03-01 21:16:47.689-05:00 | main | INFO  | KeyPairUtil | Loaded public key 0x47544ac69f628a82f1058891dc7abdf5aab5e0876381d839b7d5ea0b86bef50003a6df5abd2bc3063298b9ceddc1b64b18a399b4053ada1148b99b249a2bd465 from /home/seamonkey/.eth2/besu/key
2023-03-01 21:16:47.771-05:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: [Frontier: 0, Homestead: 1150000, DaoRecoveryInit: 1920000, DaoRecoveryTransition: 1920001, Homestead: 1920010, TangerineWhistle: 2463000, SpuriousDragon: 2675000, Byzantium: 4370000, Petersburg: 7280000, Istanbul: 9069000, MuirGlacier: 9200000, Berlin: 12244000, London: 12965000, ArrowGlacier: 13773000, GrayGlacier: 15050000]
2023-03-01 21:16:47.785-05:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: [Frontier: 0, Homestead: 1150000, DaoRecoveryInit: 1920000, DaoRecoveryTransition: 1920001, Homestead: 1920010, TangerineWhistle: 2463000, SpuriousDragon: 2675000, Byzantium: 4370000, Petersburg: 7280000, Istanbul: 9069000, MuirGlacier: 9200000, Berlin: 12244000, London: 12965000, ArrowGlacier: 13773000, GrayGlacier: 15050000]
2023-03-01 21:16:47.788-05:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: []
2023-03-01 21:16:48.059-05:00 | main | INFO  | TransactionPoolFactory | Enabling transaction pool
2023-03-01 21:16:48.059-05:00 | main | INFO  | TransactionPoolFactory | Disabling transaction handling during initial sync
2023-03-01 21:16:48.061-05:00 | main | INFO  | EthPeers | Updating the default best peer comparator
2023-03-01 21:16:48.075-05:00 | main | INFO  | BesuControllerBuilder | TTD difficulty is present, creating initial sync for PoS
2023-03-01 21:16:48.084-05:00 | main | INFO  | CheckpointDownloaderFactory | Checkpoint sync was requested, but cannot be enabled because the local blockchain is not empty.
2023-03-01 21:16:48.084-05:00 | main | INFO  | TransitionBesuControllerBuilder | TTD present, creating DefaultSynchronizer that stops propagating after finalization
2023-03-01 21:16:48.096-05:00 | main | INFO  | RunnerBuilder | Detecting NAT service.
2023-03-01 21:16:48.137-05:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: []
2023-03-01 21:16:48.195-05:00 | main | INFO  | AbstractProtocolScheduleBuilder | Protocol schedule created with milestones: []
2023-03-01 21:16:48.238-05:00 | main | INFO  | Runner | Starting external services ...
2023-03-01 21:16:48.239-05:00 | main | INFO  | JsonRpcHttpService | Starting JSON-RPC service on <IP_ADDRESS>:8547
2023-03-01 21:16:48.301-05:00 | vert.x-eventloop-thread-3 | INFO  | JsonRpcHttpService | JSON-RPC service started and listening on <IP_ADDRESS>:8547
2023-03-01 21:16:48.301-05:00 | main | INFO  | EngineJsonRpcService | Starting JSON-RPC service on <IP_ADDRESS>:8551
2023-03-01 21:16:48.304-05:00 | vert.x-eventloop-thread-3 | INFO  | EngineJsonRpcService | JSON-RPC service started and listening on <IP_ADDRESS>:8551
2023-03-01 21:16:48.306-05:00 | main | INFO  | AutoTransactionLogBloomCachingService | Starting auto transaction log bloom caching service.
2023-03-01 21:16:48.306-05:00 | main | INFO  | LogBloomCacheMetadata | Lookup cache metadata file in data directory: /home/seamonkey/.eth2/besu/caches
2023-03-01 21:16:48.310-05:00 | main | INFO  | Runner | Starting Ethereum main loop ...
2023-03-01 21:16:48.310-05:00 | main | INFO  | NatService | No NAT environment detected so no service could be started
2023-03-01 21:16:48.310-05:00 | main | INFO  | NetworkRunner | Starting Network.
2023-03-01 21:16:48.311-05:00 | main | INFO  | DefaultP2PNetwork | Starting DNS discovery with URL<EMAIL_ADDRESS>2023-03-01 21:16:48.344-05:00 | nioEventLoopGroup-2-1 | INFO  | RlpxAgent | P2P RLPx agent started and listening on /[0:0:0:0:0:0:0:0]:23426.
2023-03-01 21:16:48.344-05:00 | main | INFO  | PeerDiscoveryAgent | Starting peer discovery agent on host=<IP_ADDRESS>, port=23426
2023-03-01 21:16:48.368-05:00 | vert.x-eventloop-thread-3 | INFO  | VertxPeerDiscoveryAgent | Started peer discovery agent successfully, on effective host=<IP_ADDRESS> and port=23426
2023-03-01 21:16:48.369-05:00 | vert.x-eventloop-thread-3 | INFO  | PeerDiscoveryAgent | P2P peer discovery agent started and listening on /<IP_ADDRESS>:23426
2023-03-01 21:16:48.396-05:00 | vert.x-eventloop-thread-3 | INFO  | PeerDiscoveryAgent | Writing node record to disk. NodeRecord{seq=6, publicKey=0x0347544ac69f628a82f1058891dc7abdf5aab5e0876381d839b7d5ea0b86bef500, udpAddress=Optional[/<IP_ADDRESS>:23426], tcpAddress=Optional[/<IP_ADDRESS>:23426], asBase64=-Je4QD14_gcgQKKJPYSEQahrUDQn7nXh4oYJloGQPd__qfPhe6VKE7QpZtZOfuhSAif0GCMN3IUqVDKWkZYp5KeZmVgGg2V0aMfGhPCv0OOAgmlkgnY0gmlwhBd8VMWJc2VjcDI1NmsxoQNHVErGn2KKgvEFiJHcer31qrXgh2OB2Dm31eoLhr71AIN0Y3CCW4KDdWRwgluC, nodeId=0x34ae44ec424fb35e9de56488e175f5c6ba3e4105109c60d777265eed508f509f, customFields={tcp=23426, udp=23426, ip=0x177c54c5, eth=[[0xf0afd0e3, 0x]], id=V4, secp256k1=0x0347544ac69f628a82f1058891dc7abdf5aab5e0876381d839b7d5ea0b86bef500}}
2023-03-01 21:16:48.426-05:00 | main | INFO  | DefaultP2PNetwork | Enode URL enode://47544ac69f628a82f1058891dc7abdf5aab5e0876381d839b7d5ea0b86bef50003a6df5abd2bc3063298b9ceddc1b64b18a399b4053ada1148b99b249a2bd465@<IP_ADDRESS>:23426
2023-03-01 21:16:48.427-05:00 | main | INFO  | DefaultP2PNetwork | Node address 0xe175f5c6ba3e4105109c60d777265eed508f509f
2023-03-01 21:16:48.443-05:00 | main | INFO  | NetworkRunner | Supported capabilities: [eth/63, eth/64, eth/65, eth/66, eth/67, eth/68], [snap/1]
2023-03-01 21:16:48.444-05:00 | main | INFO  | DefaultSynchronizer | Starting synchronizer.
2023-03-01 21:16:48.445-05:00 | main | INFO  | TransactionPoolFactory | Enabling transaction handling following initial sync
2023-03-01 21:16:48.446-05:00 | main | INFO  | DefaultSynchronizer | Stopping block propagation.
2023-03-01 21:16:48.447-05:00 | main | INFO  | DefaultSynchronizer | Stopping the pruner.
2023-03-01 21:16:48.447-05:00 | main | INFO  | Runner | Ethereum main loop is up.
2023-03-01 21:16:52.271-05:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-03-01 21:16:52.272-05:00 | vert.x-worker-thread-0 | INFO  | BackwardsSyncAlgorithm | Current backward sync session is done
2023-03-01 21:16:52.364-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcece3c3436ed52276abdebe0ca6e45e45ee6c0a37039594c74410a399ff68481
2023-03-01 21:17:08.752-05:00 | Timer-0 | WARN  | DNSResolver | I/O exception contacting remote DNS server when resolving 3NL66VB5IUQZMGNON777AT.all.mainnet.ethdisco.net
java.io.IOException: Timed out while trying to resolve 3NL66VB5IUQZMGNON777AT.all.mainnet.ethdisco.net./TXT, id=21881
        at org.xbill.DNS.Resolver.send(Resolver.java:170)
        at org.apache.tuweni.discovery.DNSResolver.resolveRecordRaw(DNSResolver.kt:155)
        at org.apache.tuweni.discovery.DNSResolver.resolveRecord(DNSResolver.kt:73)
        at org.apache.tuweni.discovery.DNSResolver.internalVisit(DNSResolver.kt:175)
        at org.apache.tuweni.discovery.DNSResolver.internalVisit(DNSResolver.kt:184)
        at org.apache.tuweni.discovery.DNSResolver.internalVisit(DNSResolver.kt:184)
        at org.apache.tuweni.discovery.DNSResolver.internalVisit(DNSResolver.kt:184)
        at org.apache.tuweni.discovery.DNSResolver.internalVisit(DNSResolver.kt:184)
        at org.apache.tuweni.discovery.DNSResolver.visitTree(DNSResolver.kt:135)
        at org.apache.tuweni.discovery.DNSResolver.visitTree(DNSResolver.kt:111)
        at org.apache.tuweni.discovery.DNSResolver.collectAll(DNSResolver.kt:95)
        at org.apache.tuweni.discovery.DNSTimerTask.run(DNSDaemon.kt:89)
        at java.base/java.util.TimerThread.mainLoop(Timer.java:566)
        at java.base/java.util.TimerThread.run(Timer.java:516)
2023-03-01 21:19:13.957-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcece3c3436ed52276abdebe0ca6e45e45ee6c0a37039594c74410a399ff68481
2023-03-01 21:19:13.957-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xcece3c3436ed52276abdebe0ca6e45e45ee6c0a37039594c74410a399ff68481
2023-03-01 21:19:37.082-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x1d3b6ee73952cde028ecc5bc454649c62c3ecebfdfdc07c2da387a940549b1e2
2023-03-01 21:19:56.241-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x56b109f5a2d153f7080d1896281df50e1dd317c9ef0c166582b394470cca17ae
2023-03-01 21:20:03.448-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x495b976cbf1347900238bc18518521a8d495c6715f8d71a60023ec8b253de650
2023-03-01 21:20:10.594-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x39b168ade390645fc468cc3df28a6ff0e8f42885ed4588546673d7847a01cebe
2023-03-01 21:20:17.329-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x087956e866f8d091659310983d08963aa846f5f8e265a6702b7a24e885372b4c
2023-03-01 21:20:23.980-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xd9b95a42d1b11f3caef855bd987b1b6f5f7620dd010f9536720c68f4cd3be637
2023-03-01 21:20:30.681-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x988061c6504742fecf488e70c2ef9c82f81a044e3456d3a3dd70976cf9caa465
2023-03-01 21:20:37.464-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x857795d1050a7c047841308a778493bf0a3ee991443d6dbfe804204970edfb31
2023-03-01 21:20:39.664-05:00 | Timer-0 | INFO  | DNSResolver | Resolved 2409 nodes
2023-03-01 21:20:45.318-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x5155e2ca4481da84d0e092aae026628922df747ff8ab9e1765d0d3156dd1a396
2023-03-01 21:20:46.940-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x5155e2ca4481da84d0e092aae026628922df747ff8ab9e1765d0d3156dd1a396
2023-03-01 21:20:47.496-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x5155e2ca4481da84d0e092aae026628922df747ff8ab9e1765d0d3156dd1a396
2023-03-01 21:20:52.665-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x0c29d67fa5587244420ec51f0c9e43b3814a4d3cae03ff0738b90c0fbb0814e1
2023-03-01 21:20:59.591-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xa5dd354b7139fc1b27739c2646f7dd9d258cd2d3545cdcc48e3320726d025e12
2023-03-01 21:21:00.021-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0xdc7c68f450994b3ecc3b26cf8226d7ca8a0c498cf3325f1e9714442123798889
2023-03-01 21:21:06.781-05:00 | vert.x-worker-thread-0 | WARN  | MergeCoordinator | Internal error, backward sync completed but failed to import finalized block 0x4d888bc62b40fa4f61af28a6c8402bc3ff18caac9f1f6ea491ff75f61b8ea453

Same problem here, twice in one week.

Hi @SgtDinosaur which Besu version, sync-mode and CL are you using?

I was using the second latest and then switched to the latest in the hope of fixing the issue. I now switched to Nethermind, hope to come back quick. My CL was Lighthouse.
Thank you guys for responding and looking into it!

This fix has been released in https://github.com/hyperledger/besu/releases/tag/23.1.2


Rename :other option of compile task

Right now we are using :other to add custom compiler arguments to a compile task,
but the name is misleading and should indicate that we are appending more compiler arguments.
Need to come up with a good name.

:optional
:additional
:append
:args
:optional_args

compile.using(:mcmlc, :args => ["-compiler.incremental=true","...etc"]) could work


Open API specification should contain enums of possible parameters

Use the OAS spec enum rather than written examples

@bilalshaikh42 I don't think we can do this in dispatch-api, because all the places where the API expects a string, they are dynamic values. I don't think we can hardcode anything in enums. Do you have any other  suggestion?
SO for selecting the simulator info, we already have /api/simulators to get all possible simulators and their versions. It's not working ever since we migrated from crbm to biosimulators docker hub repo but will be fixed when #1099 is closed.


updating abPOA

Is there any reason not to update abPOA to the most-recent version?
It looks like there is an incompatibility with the arguments to abpoa_msa. It seems minor, but I wanted to check if there is a hidden gotcha here.

Actually, no particular reason.
I will update it later.

Updated to the latest abPOA.


Something seams wrong in SessionServiceProvider

Hi,
it's not a bug since nothing is broken (yet), but there is something odd on lines 41 and 64 of the SessionServiceProvider (master)
line 41:
return new Session($app['session.storage']);

the Session __constructor() signature is:
public function __construct(SessionStorageInterface $storage = null, AttributeBagInterface $attributes = null, FlashBagInterface $flashes = null)

line 64:
return new SessionListener($app, $app['session.attribute_bag'], $app['session.flash_bag']);

the SessionListener __constructor() signature is:
public function __construct(Container $app)

To me it seams like some kind of inversion mistake.

Yup, looks like a bug to me.


DRAFT: Feature/mira pipeline

Add Mira pipeline integration

Closing as out of date and Mira not being actively developed.


wrong syntax

https://github.com/BobBuildTool/basement/blob/6878d4e8276588e353a7b962a32d9e1d22e8044a/classes/make.yaml#L5
- make -j "${MAKE_JOBS-$(nproc)}" "$@"
+ make -j "${MAKE_JOBS:-$(nproc)}" "$@"

same here:
https://github.com/BobBuildTool/basement/blob/c2a5d96fdba5d990666fb9d662248e8370c5bd25/recipes/devel/cmake.yaml#L61
BR.

What's exactly wrong? The syntax is valid bash AFAICT.

really, not missing a ":" in front of the "-"?

Am 27. Juli 2020 15:29:05 MESZ schrieb Martin Haase<EMAIL_ADDRESS>
really, not missing a ":" in front of the "-"?

No, not really. The colon makes the difference if the variable is defined but empty. See https://www.tldp.org/LDP/abs/html/parameter-substitution.html

waahh! hkay! sry! xD


Vis Issues (v1.8 Extensions API)

A few issues noted while trying out the new features of the Viz in version 1.8 of the Extensions API.

The Custom Title attribute for row and column values in the dataSpec don’t always work. Even if it works, it only works for either the row or column but not both.
The middle colour in tableau.VizImagePaletteType.CustomDiverging is always grey.
The starting colour in tableau.VizImagePaletteType.CustomSequential is always grey.
The new sort feature doesn’t always work. Throws the following error:

Error: internal-error: {"vizapiErrorMsg":"Build Partition Model failed\r\nInternal Error - An unexpected error occurred and the operation could not be completed.\n\nLogicException details: LogicAssert at /Volumes/build/tc/t214/g_pc/tableau-build/bazel/output/external/tabsys__osx_release/include/tabsys/ReferenceCount.h line 340: Null pointer dereferenced\n"}

~AppsForTableau | Infotopics

Thank you @sri4tableau, I'll share your feedback with the vizAPI team.
John

@sri4tableau the vizAPI team has done some investigation. I'm going to put you in contact directly with them. I'm just waiting for confirmation on what contact to use.
Meanwhile, here is their preliminary investigation for #1 and #4:

The Custom Title attribute for row and column values in the dataSpec don’t always work. Even if it works, it only works for either the row or column but not both.

VizAPI only allows customizing axis titles. I've tried Tableau to see if it allows customizing the header (discrete) title. It doesn't seem to support it. If the user tried to customize the title for the discrete field, it wouldn't work. I've tried a viz with axis x axis. In that case, I was able to set up the custom title for both row and column. [Perhaps documentation needs to be clarified]

The new sort feature doesn’t always work. Throws the following error:

Is there a way to get user's data?

For the custom diverging and custom sequential, since the API currently doesn't support a step count, the middle (or first color) will always be gray. For example, see:

and...


Load balancing handler 3 times faster

Coverage decreased (-0.9%) to 64.865% when pulling 254a0e2770ddedcbc5f4a0f4758c16746f206f52 on tianxiaoliang:perf into 9ebb47283309d6de2cd18cf89e9b86c7a8ed745b on ServiceComb:master.


Continuous web job example

I'm having trouble finding a correlation between the Host in the example and continuous web jobs. It states that The host is the runtime container for functions that listens for triggers and calls functions. But what if I don't have functions that listen for triggers? I have a continuous web job that performs background tasks. I'm trying to integrate application insights into this web job, but there is 0 example on how to use the Host with a continuous web job without triggers.
Could anyone elaborate on this?

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

ID: 2e9e1a8a-6284-a230-061e-7cb27258571a
Version Independent ID: 43390e30-04d6-6d4e-018e-21419dbb11e8
Content: Tutorial for event-driven background processing with the WebJobs SDK - Azure App Service
Content Source: articles/app-service/webjobs-sdk-get-started.md
Service: app-service
GitHub Login: @ggailey777
Microsoft Alias: glenga

PaulVrugt, Apologies for the delay.  Here the ‘WebJobs host’ –  The Host listens for triggers and calls functions. You can create a host instance in your code and write code to customize its behavior.
This is a key difference between using the WebJobs SDK directly and using it **indirectly **through Azure Functions.
In Azure Functions, the service controls the host, and you can't customize the host by writing code. Azure Functions lets you customize host behavior through settings in the host.json file. Those settings are strings, not code, and use of these strings limits the kinds of customizations you can do.
Kindly see this sample for more details:
Host connection strings | sample
Additionally, to provide more clarity:
All Web Apps have both a main site and an SCM site (where Kudu runs, including WebJobs). Just note that when you click Stop in the portal, only the main site is stopped, while the SCM site keeps running.
If a continuous job is set as singleton it'll run only on a single instance opposed to running on all instances. By default, it runs on all instances.
Set-a-continuous-job-as-singleton
Azure Functions is built on the WebJobs SDK, so it shares many of the same event triggers and connections to other Azure services. You may wish to know, here are some factors to consider when you're choosing between Azure Functions and WebJobs with the WebJobs SDK.

@AjayKumar-MSFT
Thanks for the reply!
So if I understand correctly continuous web jobs simply shouldn't use the webjobs sdk? If this is true, how does application insights integration work with continuous web jobs?
I'm not sure why you're bringing up Azure Functions. Maybe for background information? We're not using Azure Functions. We're using web jobs.
So my actually my question remains the same:
how does application insights integration work with continuous web jobs?

PaulVrugt, Thanks for the follow-up.  Apologies for any confusion, yes I'd shared info about Azure Functions for comparison and background info.
A webjob using the webjob SDK should be deployed as a continuous webjob.
Usually you'll host the WebJobs SDK (framework) in Azure WebJobs, but you can also run your jobs in a Worker Role. So they are different but can run together.
So, further to highlight -the webjob sdk as any other sdk that allows you to trigger based on events. The SDK can be used in a console app (ie a webjob if deployed to a web app) or in something like a function app which is built using the webjob sdk.
-I'm also sharing your feedback with the content author @ggailey777 for a review to see if any additional clarity on this is required in the doc for future revisions.
We will close this for now, if you have any further questions please just let us know. Thanks again for taking time to share your feedback. It's much appreciated.

@AjayKumar-MSFT
Hello AjayKumar-MSFT,
thank you for the quick reply!
I understand now how the WebJob SDK should be used, but to be honest, you haven't answered my question. Since my WebJob is a continuous Web Job that doesn't use triggers, I don't think (taking from your explanation of the webjob sdk) I can use the WebJob SDK (we have our own mechanism built into the WebJob that determines when actions should be taken).
So when not using the WebJob SDK, how can I integrate application insights monitoring in my Web Job? The examples only show how to enable application insights when using the WebJob SDK


How to convert to raw JSON string

I'm converting my project to go from SwiftyJSON to JASON
SwiftyJSON allows you to convert the JSON to a rawJSON string like so: json.rawString()
How can I achieve this in JASON?
Sorry for the newbie question.

There is no way doing that with JASON and there is no plan implementing it. Sorry :/


Gitlab.com restricting the creating/viewing of application from API

If solved, this could simplify the process of creating an application on gitlab.com

Trying to access the gitlab.com's /applications endpoint [1] can result in a 403 Forbidden error. This can be easily checked by running this command:
curl -X GET https://gitlab.com/api/v4/applications -H 'private-token: redacted'

Output:
{"message":"403 Forbidden"}

The private token can be generated in gitlab.com, and even with all the permissions set, 403 Forbidden is still being hit. [1] mentions that this is an Administrator API (Only administrator users can use the Applications API.), however, you are able to view / create Applications in gitlab.com easily and without any issues.
We're using that API to list the applications and then create an application in the Legend Juju GitLab Integrator Charm. But because of this issue, we can't have the Charm create an application automatically for us, we have to create the Application manually ourselves, and then pass in to the Charm the bypass-client-id and bypass-client-secret config options. This basically adds quite a few extra steps to getting started with Legend.
[1] https://docs.gitlab.com/ee/api/applications.html

Opened forum post: 403 Forbidden when accessing the https://gitlab.com/api/v4/applications API: https://forum.gitlab.com/t/getting-the-ssl-certificate-in-python-ends-with-a-ssl-sslv3-alert-handshake-failure-error/64590
Opened feature request: CRUD User Applications through the API: https://gitlab.com/gitlab-org/gitlab/-/issues/358133#note_905090798
Opened feature request: /applications API - update existing applications not available: https://gitlab.com/gitlab-org/gitlab/-/issues/359065
Related: https://github.com/finos/legend-juju-gitlab-integrator/issues/10


worked, run notes... gpt-4o?

Discussed in https://github.com/ottoweiss/pdf-to-audiobook/discussions/4

Originally posted by drhouse May 19, 2024
it worked, cheers :)
just wanted to leave my notes for anyone else:
ModuleNotFoundError: No module named 'frontend'
fixed with: 'pip install PyMuPDF'
ModuleNotFoundError: No module named 'tf_keras'

ValueError: Your currently installed version of Keras is Keras 3, but this is not yet supported in Transformers. Please install the backwards-compatible tf-keras package with pip install tf-keras.

fixed with: 'pip install tf-keras'

by any chance, would using GPT-4o cost less or speed anything up?

Thank you for catching that, added gpt-4o now too


Building errors using VS code and Windows

Dear all,
I've been trying to install openFAST for some days now, but without any success.
The guide that I'm working with is this.
I'm using:

Windows 10
Visual studio code 2019 (also tried 2017, 2015)
Intel Fortran (XE2019, + VS integration)
Configuration: Release, x64
Git
Upgraded the two files to their 2019 version

Furthermore, I've tried:

Redoing all steps on a new Windows account
Reopening/building VS code (multiple times), after the errors
Removing all spaces from the file path

The console output is as follows:
2>------ Build started: Project: FAST, Configuration: Release x64 ------ 2>Performing Pre-Build Event... 2>Compiling with Intel(R) Visual Fortran Compiler <IP_ADDRESS> [Intel(R) 64]... 2>FAST_Prog.f90 2>Linking... 2>ipo: error #11018: Cannot open C:\Users\me\Downloads\code\openfast\build\bin\Registry.lib 2>ipo: error #11018: Cannot open mkl_intel_lp64 2>ipo: error #11018: Cannot open mkl_sequential 2>ipo: error #11018: Cannot open mkl_core 2>ipo: warning #11021: unresolved DGBSV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGBSV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DGEMM 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGEMM 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DGESV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGESV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DGETRF 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGETRF 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DGETRS 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGETRS 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DGETRI 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGETRI 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DGGEV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGGEV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DPOSV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SPOSV 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DPPTRF 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SPPTRF 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved DGESVD 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved SGESVD 2>        Referenced in FASTlib_x64.lib(NWTC_LAPACK.obj) 2>ipo: warning #11021: unresolved LSAME 2>        Referenced in FASTlib_x64.lib(dlasrt2.obj) 2>        Referenced in FASTlib_x64.lib(slasrt2.obj) 2>ipo: warning #11021: unresolved XERBLA 2>        Referenced in FASTlib_x64.lib(dlasrt2.obj) 2>        Referenced in FASTlib_x64.lib(slasrt2.obj) 2>ipo: error #11023: Not all components required for linking are present on command line 2>LINK : fatal error LNK1181: cannot open input file 'C:\Users\me\Downloads\code\openfast\build\bin\Registry.lib' 2> 2>Build log written to  "file://C:\Users\me\Downloads\code\openfast\vs-build\FAST\x64\Release\BuildLog.htm" 2>FAST - 6 error(s), 22 warning(s) ========== Build: 1 succeeded, 1 failed, 2 up-to-date, 0 skipped ==========
Please help me with with a solution, such I can resolve these errors.

This issue has been solved by installing Fortran 2017 together with VS code 2015.

Hello,
I have also met the same problem. I wan to know how to solve that
I'm using:
Windows 10
Visual studio code 2017
Intel Fortran (XE2020, + VS integration)
Configuration: Release_double, x64
Git
Upgraded the two files to their 2019 version
Instead of using Fortran 2017 and VS code,  can I solve that ?

Hello,
I have also met the same problem. I wan to know how to solve that
I'm using:
Windows 10
Visual studio code 2017
Intel Fortran (XE2020, + VS integration)
Configuration: Release_double, x64
Git
Upgraded the two files to their 2019 version
Instead of using Fortran 2017 and VS code, can I solve that ?
Here is the problem:
Deleting intermediate files and output files for project 'FAST', configuration 'Release_Double|x64'.
Performing Pre-Build Event...
..\CreateGitVersion.bat
Compiling with Intel(R) Visual Fortran Compiler <IP_ADDRESS> [Intel(R) 64]...
ifort /nologo /O2 /Qipo /fpp /I"C:\Users\Windlover\Desktop\code\openfast\vs-build\FASTlib\x64\Release_Double" /DDOUBLE_PRECISION /stand:f03 /Qdiag-disable:5268,5199 /real-size:64 /double-size:128 /module:"x64\Release_Double\" /object:"x64\Release_Double\" /Fd"x64\Release_Double\vc150.pdb" /libs:static /threads /Qmkl:sequential /c /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64" /Qm64 "C:\Users\Windlover\Desktop\code\openfast\glue-codes\openfast\src\FAST_Prog.f90"
Linking...
Link /OUT:"....\build\bin\openfast_x64_Double.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST:NO /SUBSYSTEM:CONSOLE /STACK:9999999 /IMPLIB:"C:\Users\Windlover\Desktop\code\openfast\build\bin\openfast_x64_Double.lib" -qm64 /qoffload-ldopts="-mkl=sequential" "x64\Release_Double\FAST_Prog.obj" "C:\Users\Windlover\Desktop\code\openfast\build\bin\MAP_x64.lib" "C:\Users\Windlover\Desktop\code\openfast\build\bin\FASTlib_x64_Double.lib" "C:\Users\Windlover\Desktop\code\openfast\build\bin\Registry.lib"
ipo: error #11018: Cannot open C:\Users\Windlover\Desktop\code\openfast\build\bin\Registry.lib
LINK : fatal error LNK1181: 无法打开输入文件“C:\Users\Windlover\Desktop\code\openfast\build\bin\Registry.lib”
FAST - 2 error(s), 0 warning(s)

Thanks to your reponses.   I try again to install the openfast. I deleted the previous Visual Studio 2017 and reinstall Visual Studio 2017 also with l Intel Fortran (XE2020, + VS integration).
I follow the the https://openfast.readthedocs.io/en/master/source/install/.

Used the files from https://github.com/openfast/openfast.git

Opened FAST.sln

Accepted to upgrade VC++ Compiler and Libraries
4 Chose Release and x64, then Build Solution (not Build FAST).
This time do not have errors but I only have thses files not including openfast_x64.exe

I try to close and reopen the FAST.sln many times.  It have no errors but always without  openfast_x64.exe.

In addition , I can  successfully build the  DISCON DLLs with Discon.sln. However with FAST.sln,  Chose Release_double and x64, then Build Solution.  It also have no errors but can't build openfast_x64_double.exe

Then I try to use the "windows_openfast_binaries" download form https://github.com/OpenFAST/openfast/releases to do regression tests.  Sadly, All failed!

Finally, I also try to run the one example in 0C4 project with jacket foundation in 5MW example. It also failed.

I am newer of  Visual Studio.  Thus, I do not know to solve the problem. In addition, If I only want to use the "5MW_OC4Jckt_ExtPtfm" and "5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth",  Can i use the windows_openfast_binaries download form https://github.com/OpenFAST/openfast/releases ???
Looking forward to your reply. Thanks again!!!

If you do not plan to change any source code, then yes, you can just use the binaries from https://github.com/OpenFAST/openfast/releases. The last error you display here seems to be caused by an InflowWind input file that is not in the correct format for the version of OpenFAST you are using.
I do find it strange that the openfast executable file is not in the build/bin directory if you have no build errors. If you do need help debugging that, please attach the text from Visual Studio's Output tab (showing output from the build). But, I'd recommend just using the binaries in the OpenFAST releases page.

Thanks for your reply.  Here is the output from Fast.sln (Chose Release and x64, then Build Solution). I am sorry that there are Chinese words in output. I hope that It will have not effect on you to read the output results.

The end line of the output says:  Succeed 2,  fail 0,  skip 0

I change the language in English and rebuild with Fast.sln (Chose Release and x64, then rebuild Solution)
The output is :
1>------ Rebuild All started: Project: FAST_Registry, Configuration: Release x64 ------
1>data.c
1>gen_c_types.c
1>gen_module_files.c
1>c:\users\windlover\desktop\code\openfast\modules\openfast-registry\src\gen_module_files.c(2354): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
1>c:\users\windlover\desktop\code\openfast\modules\openfast-registry\src\gen_module_files.c(2366): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
1>misc.c
1>my_strtok.c
1>registry.c
1>reg_parse.c
1>c:\users\windlover\desktop\code\openfast\modules\openfast-registry\src\reg_parse.c(272): warning C4102: 'normal': unreferenced label
1>sym.c
1>symtab_gen.c
1>type.c
1>c:\users\windlover\desktop\code\openfast\modules\openfast-registry\src\type.c(187): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
1>Generating code
1>All 74 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
1>Finished generating code
1>FAST_Registry.vcxproj -> C:\Users\Windlover\Desktop\code\openfast\vs-build\Registry....\build\bin\Registry.exe
1>Done building project "FAST_Registry.vcxproj".
2>------ Rebuild All started: Project: MAP_dll, Configuration: Release x64 ------
2>Performing Custom Build Tools
2>======================================================================
2>
2>----- FAST Registry --------------
2>----------------------------------------------------------
2>input file: ....\modules\map\src\MAP_Registry.txt
2>opening ....\modules\nwtc-library\src/Registry_NWTC_Library.txt
2>generating ....\modules\map\src/MAP_Types.f90
2>CUSTOMBUILD : Registry warning : derived data type Ver of type progdesc is not passed through C interface
2>CUSTOMBUILD : Registry warning : derived data type PtFairDisplacement of type meshtype is not passed through C interface
2>CUSTOMBUILD : Registry warning : derived data type ptFairleadLoad of type meshtype is not passed through C interface
2>
2>Registry for MAP completed.
2>
2>======================================================================
2>bstraux.c
2>c:\users\windlover\desktop\code\openfast\modules\map\src\bstring\bstraux.c(1004): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data
2>c:\users\windlover\desktop\code\openfast\modules\map\src\bstring\bstraux.c(1017): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
2>bstrlib.c
2>c:\users\windlover\desktop\code\openfast\modules\map\src\bstring\bstrlib.c(367): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data
2>dpmpar.c
2>enorm.c
2>enorm_u.c
2>lmder.c
2>lmpar.c
2>qrfac.c
2>qrsolv.c
2>freedata.c
2>jacobian.c
2>lineroutines.c
2>mapapi.c
2>c:\users\windlover\desktop\code\openfast\modules\map\src\mapapi.h : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss
2>maperror.c
2>mapinit.c
2>numeric.c
2>outputstream.c
2>residual.c
2>simclist.c
2>lmroutines.cc
2>   Creating library ....\build\bin\MAP_x64.lib and object ....\build\bin\MAP_x64.exp
2>Generating code
2>All 293 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
2>Finished generating code
2>MAP_dll.vcxproj -> C:\Users\Windlover\Desktop\code\openfast\vs-build\MAPlib....\build\bin\MAP_x64.dll
2>Done building project "MAP_dll.vcxproj".
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========

It looks like it is recognizing and building only the projects written in C/C++, and not the Fortran projects. Are you sure you installed the Intel Fortran integrations into this version of Visual Studio (after you installed Visual Studio)?
A screen shot of the solution file open in Visual Studio might help.

Thanks for your reply. Here is screen shot of Visual Studio. Here shows that i have Intel Fortran integrations.

But when I open that FAST.lsn and I see can only build these two.

But when I open that FASTlib.lsn and I see can only build these three.

In addition, you are right about the  InflowWind input file.  If I changed that and used one in FASTv8,  It worked

Well, I still have some questions about the Openfast and Fastv8

One is about the exe. files. In Fastv8 , I see there are Fast_x64.exe and Fast_x64d.exe. In openfast, there are also two for x64(Openfast_x64 and Openfast_x64_double). What is the differences?  If using x64 or x64_double, the results of simualtions will be different?

It is about the AeroDyn module.  There are two files AeroDyn14 and AeroDyn15 in FASTv8.  What is the differences?  Also, I know, for different wind speed , I need to intialize the  rotor speed and pitch angle.  I want to know how much rotor speed and pitch angle I should set for a given wind speed? Does that have a rule or an equation?  Could you give me some references?  In addition, If using AeroDyn15,  sometimes FAST will abort at the beginning or during the Fast simulation due to high attack angle ( I can change the High attack limit in the given file but It also happens). However with AeroDyn14, It will not happen. Thus, I would like to know that the differences between the two AeroDyn is huge or not?

file)

It about the 5MW_OC4Jckt_ExtPtfm module. I try to run that but failed. It is also the problem of input file???  How could I fix that (In FASTv8, It does not have this file)? In addition, for the ExtPtfm module, how could I import my new platform matrix using superelement(substructure) method? Do you have any tutorial, technical report or paper about this part?  Thanks!!!

Any way, thank you very much. Your replys are very useful and really save my life!  Looking forward to your responses

Can you show me the "Solution Explorer" tab instead of the "Team Explorer" tab?

Here is the "Solution explorer". It shows that FAST and FASTlib incompatible!  how could i fix that?

This sometimes happens if you've installed the Fortran integrations in the wrong order or you've upgraded Visual Studio.
Right click on the incompatible projects. It should give you a list of options; I don't recall what they all are at the moment, but hopefully one will stand out to you as the correct one to choose for Fortran projects.

Thanks for your reply.  Now my interest is  more about the following questions.  Do you have any answers for these?  Especially for the question 3?

You are right about the InflowWind input file. If I changed that and used one in FASTv8, It worked. i used that windows binaries download from the site!

Here are some questions about the Openfast and Fastv8

One is about the exe. files. In Fastv8 , I see there are Fast_x64.exe and Fast_x64d.exe. In openfast, there are also two for x64(Openfast_x64 and Openfast_x64_double). What is the differences?  If using x64 or x64_double, the results of simualtions will be different?

It is about the AeroDyn module.  There are two files AeroDyn14 and AeroDyn15 in FASTv8.  What is the differences?  Also, I know, for different wind speed , I need to intialize the  rotor speed and pitch angle.  I want to know how much rotor speed and pitch angle I should set for a given wind speed? Does that have a rule or an equation?  Could you give me some references?  In addition, If using AeroDyn15,  sometimes FAST will abort at the beginning or during the Fast simulation due to high attack angle ( I can change the High attack limit in the given file but It also happens). However with AeroDyn14, It will not happen. Thus, I would like to know that the differences between the two AeroDyn is huge or not?

file)

It about the 5MW_OC4Jckt_ExtPtfm module. I try to run that but failed. It is also the problem of input file???  How could I fix that (In FASTv8, It does not have this file)? In addition, for the ExtPtfm module, how could I import my new platform matrix using superelement(substructure) method? Do you have any tutorial, technical report or paper about this part?  Thanks!!!

Any way, thank you very much. Your replys are very useful and really save my life! Looking forward to your responses

I suggest you start reviewing some of the documentation and perhaps go through some of the exercises from past modeling workshops here: https://wind.nrel.gov/forum/wind/viewtopic.php?f=38&t=653. Also, you will find input files for the current version of OpenFAST on the r-test repository: https://github.com/OpenFAST/r-test/tree/master/glue-codes/openfast.
Then, if you still have questions, start a new issue here or ask a question on the forum so someone with more modeling expertise can help you.

Ok, thanks a lot!

Hello Sir, Ma'am,
I try to use the "windows_openfast_binaries" (Since I do not plan to change any source code) download form https://github.com/OpenFAST/openfast/releases to do regression tests but upon running its shows some error like.. {{
FAST_InitializeAll:SrvD_Init:BladedInterface_Init:The dynamic library
.../5MW_Baseline/ServoData/DISCON.dll could not be loaded. Check that the file exists in the
specified location and that it is compiled for 32-bit applications.}}
I am new to this tool and trying my level best to get it done but still strugling hard for solution

@mishtiyak
If you downloaded the binaries from https://github.com/OpenFAST/openfast/releases/tag/v2.4.0, the controller DLL's you need will be located inside the folder DISCON_DLLS\Win32. You will need to change the location of the DLL in the ServoDyn input files to match where you downleaded the DLL to.

Dear Sir @andrew-platt, Issue got resolved.
Thank you very much for your quick response.

Dear Sir/Ma'am,
I am running "5MW_OC3Mnpl_DLL_WTurb_WavesIrr" and I see below warning message stating that the Mach number exceeds 0.3 and the theory is invalid. However, the simulation doesn't abort.
I see this warning message when I run with higher wind speed (i.e 25m/s). Could you please suggest me way ahead.
Thank you

Did you change the initial blade pitch for the higher wind speed simulation?  If not, the blade pitch is likely around 0 degrees at the start of the simulation which will cause large transients in blade motion initially.
Ideally you set the initial conditions in the ElastoDyn input file (blade pitch, rotor speed etc) to match the steady state conditions for that wind speed.  This will reduce the initial transients of the simulation and likely get rid of this warning. During steady state operation, the blade pitch will likely be around 20 degrees or so (I don't remember the exact value) at 25 m/s wind speed. So I suggest you run steady wind with ramping wind speed to find the those steady state conditions.

Dear Sir @andrew-platt,
Thank you for your quick help. The issue has been resolved now.
However, I come up with a new issue now.

When I run "5MW_OC3Mnpl_DLL_WTurb_WavesIrr" with DT=0.05 I see below error message (However,with DT=0.005, NO error)

If running with DT=0.005 is the only solution, do I need to run ANSYS simulations with time step size =0.005 sec too? Actually, i am importing aerodyne forces into ANSYS for FEA analysis purposes.

Also turbsim throwing some error with DT=0.005

Is it mandatory to keep the uniform time step size across Turbsim, FAST, and ANSYS for simulation? Earlier I was running Turbsim with DT=0.05 and than FAST' test19 with DT=0.005 and finally ANSYS with DT=0.05. Can I go this way also? Please share your valuable suggestions.

Thanking you

Dear @mishtiyak,
Here are my answers to your questions:

The time step requirements in OpenFAST are dictated by the natural frequencies of the coupled system.  The time step for the OC3-monopile model should be 0.005 s, unless you've disabled features (degrees of freedom) that would permit the use of a larger time step.  Increasing the time step without disabling features is making your model numerically unstable.  Guidelines for choosing time steps in OpenFAST have been discussed many times on our forum: https://wind.nrel.gov/forum/wind/.

I gather you are using a one-way coupling to ANSYS, i.e., you are calculating the aerodynamic loads from OpenFAST and applying them to the ANSYS model without transferring information from ANSYS to OpenFAST?  In this case, I would expect you could use distinct time steps between ANSYS and OpenFAST.  If ANSYS runs with a time step 0.05 s, I would run OpenFAST at 0.005 s but output the OpenFAST time-series data at DT_Out = 0.05 s.

The TurbSim and OpenFAST time steps do not need to be identical.  Running TurbSim with a time step of 0.005 would require a large amount of memory, which it doesn't appear that you have.  But there is no reason to run TurbSim with time step smaller than 0.05 s.

Yes, that is OK; see my answers to questions 1-3.

Best regards,

Dear Sir @jjonkman,
Thank you very much for your support. It really matters a lot to me.
Now I have come up with another issue. Could you please provide me some guidance about how to perform Modal Analysis for Test19 (OC3 Monopile)? I want to compare natural frequencies obtained from FAST with my Ansys Model.
Thank you

Dear @mishtiyak,
The OC3 monopile model in the r-test uses SubDyn to model the substructure (pile).  The linearization functionality in the current master branch of OpenFAST (v2.4) does not support full-system linearization with SubDyn enabled.  That said, we have recently added this capability, which is included in the following pull request, which is still be reviewed before being merged into the dev branch of OpenFAST: https://github.com/OpenFAST/openfast/pull/537.
Until the new functionality is fully vetted, you cannot use a linearization analysis to perform the modal analysis.  As discussed several times on our user forum (https://wind.nrel.gov/forum/wind/), it may be possible to use white-noise wave excitation to derive full-system natural frequencies.
Best regards,

Dear Sir @jjonkman,
Thank you very much for your support.
Please have a check on the below points and share your thoughts on the same.
1.Where in the wind turbine structure, the load from the controller is applied?
2. Does it work at the node of the nacelle ? or does it act the nodes of the blades?
3.If I take the force output from the tip of the low-speed shaft, will it include the forces due to the controller's actions as well?
Thanks and Regards

Dear @mishtiyak,
I'm not sure I really understand your questions, but the electrical generator torque computed by the controller is applied to the generator, and equal and oppositely applied to the nacelle.  The yaw command is applied at the yaw bearing, with a torque equally and oppositely applied to the nacelle and tower top.  The blade-pitch is applied at the blade root/hub.  In the end, the system is coupled, so, you "feel" the effect of the controller throughout the system.
Best regards,


Persistence between runs without providing private key

What is wrong
Running the trin client in a manner that re-uses node-id and storage requires providing manual CLI args and is a barrier to entry.
How can it be fixed.
I should be able to run the bare ./trin binary without any additional arguments and it should:

[x] default to the hardcoded bootnodes if none are explicitly provided
[ ] generate a new private key for node-id if none exists.  Otherwise, it should re-use the previous one
[ ] same for storage, lazily make a new one if needed, otherwise re-use.

same for storage, lazily make a new one if needed, otherwise re-use.

This should already be done, that trin will default to using the same storage directory, if you are reusing the same node id.

I'm not likely to work on this anytime soon so I unassigned.

Ah yes, in the pared-down project view of the issue, I didn't see the link to Nick's PR to see that he's the one who started in on it.

After this issue is solved we can potentially look at also closing this issue https://github.com/ethereum/trin/issues/320 since I believe it is generally targeting the same issue.


Nripendra nipen

Adding my name -Nripendra Bhattacharjee
Screenshots (If any)
Questions

Hey @Nripendra-Bhattacharjee closing this issue due to no activity and conflicts. Please create a new PR commiting changes to only your name. Thank you!


Add throttle operator

I'm used to RxJS and loved the concept, so I wanted to use it in C++ as well. Seeing #501, I thought this would be a good opportunity for me to get a little deeper into understanding the implementation of RxCpp.
This is mostly a copy&paste of the debounce operator implementation, edited to implement throttle semantics (ref. RxJS).
The throttle operator re-emits the first value emitted by the source, then swallows all following emissions until the specified timeout has occurred. After that, the next value emitted by the source is emitted again and the cycle continues.
The RxJS implementation also supports emitting the last value emitted by the source when the timeout completes. If this is a feature you would like to see, I can add support for that as well.

Hmmm, not quite sure why the Travis build fails. It's only one and it fails to install g++-8, which all other runners have had no problems with.

Any news on this PR? Could throttle be included in RxCpp?