Build error with builtin iOS SQLite3

Hi ! It seems that when using this lib and using another lib that is using the SQLite3 from iOS SDK, the build produces an error:
❌  (ios/Pods/Headers/Public/sqlite3/sqlite3.h:7345:9)

  7343 |   /* The methods above are in versions 1 through 3 of the sqlite_module object.
  7344 |   ** Those below are for version 4 and greater. */
> 7345 |   int (*xIntegrity)(sqlite3_vtab *pVTab, const char *zSchema,
       |         ^ 'sqlite3_module::xIntegrity' from module 'sqlite3.sqlite3' is not present in definition of 'struct sqlite3_module' provided earlier
  7346 |                     const char *zTabName, int mFlags, char **pzErr);
  7347 | };
  7348 |

❌  (/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.5.sdk/usr/include/sqlite3ext.h:36:8)

  34 | ** libraries!
  35 | */
> 36 | struct sqlite3_api_routines {
     |        ^ type 'struct sqlite3_api_routines' has incompatible definitions in different translation units
  37 |   void * (*aggregate_context)(sqlite3_context*,int nBytes);
  38 |   int  (*aggregate_count)(sqlite3_context*);
  39 |   int  (*bind_blob)(sqlite3_stmt*,int,const void*,int n,void(*)(void*));

In my case, I'm using this pod called EXUpdates and this pod called AmazonChimeSDK resulting in this error.
I already fill an issue in the EXUpdates repo but maybe it belongs more to this repo I don't know. Thanks for the help 🙏

If someone finds a proper solution for this that this pod could implement, I'd love to hear about it. As a workaround, I believe you can stop other pods from linking the system's sqlite3 like this:
post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      xcconfig_path = config.base_configuration_reference.real_path
      xcconfig = File.read(xcconfig_path)
      new_xcconfig = xcconfig.sub(' -l"sqlite3"', '')
      File.open(xcconfig_path, "w") { |file| file << new_xcconfig }
    end
  end
end

I think the pods should still work since sqlite3 does end up being linked in your application thanks to the sqlite3 pod.
Other packages such as SQLite.swift come with a standalone subspec that doesn't declare sqlite3 as a library but instead depends on the pod as well. Maybe the other pods should do this as well, but it's annoying that there's no proper solution.

I'll try to see what we can do but yeah, this issue seems very common in my opinion. I'll try to investigate more
Your solution can be a great workaround but it doesn't work in my case, here is the content of the problematic pod config
Pods/Target Support Files/AmazonChimeSDKMedia/AmazonChimeSDKMedia.release.xcconfig
CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = NO
CONFIGURATION_BUILD_DIR = ${PODS_CONFIGURATION_BUILD_DIR}/AmazonChimeSDKMedia
FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/AmazonChimeSDKMedia" "${PODS_XCFRAMEWORKS_BUILD_DIR}/AmazonChimeSDKMedia"
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
OTHER_SWIFT_FLAGS = $(inherited) -D COCOAPODS -import-underlying-module -Xcc -fmodule-map-file="${SRCROOT}/${MODULEMAP_FILE}"
PODS_BUILD_DIR = ${BUILD_DIR}
PODS_CONFIGURATION_BUILD_DIR = ${PODS_BUILD_DIR}/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
PODS_DEVELOPMENT_LANGUAGE = ${DEVELOPMENT_LANGUAGE}
PODS_ROOT = ${SRCROOT}
PODS_TARGET_SRCROOT = ${PODS_ROOT}/AmazonChimeSDKMedia
PODS_XCFRAMEWORKS_BUILD_DIR = $(PODS_CONFIGURATION_BUILD_DIR)/XCFrameworkIntermediates
PRODUCT_BUNDLE_IDENTIFIER = org.cocoapods.${PRODUCT_NAME:rfc1034identifier}
SKIP_INSTALL = YES
USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES = YES

there is no occurence of sqlite3 in that, not sure how this pod is functioning
Thanks for the help, I was so stuck in my side 🙏

My other solution was to fork it and remove the system SQLite3  and instead using this lib. But I have so much trouble linking this forked pod dependency in my project.


scan task fails with internal registry,  x509: certificate signed by unknown authority

      java-microprofile-manual-pipeline-run-image-scan-task-cdvbs:
        pipelineTaskName: image-scan-task
        status:
          completionTime: "2019-11-05T13:51:06Z"
          conditions:
          - lastTransitionTime: "2019-11-05T13:51:06Z"
            message: '"step-mount-image" exited with code 2 (image: "docker.io/appsody/appsody-buildah@sha256:4a9941d67464af5594eddf0b3e816fbb6ac6164fa2d27d269cbaa6ab6f3f3eb1");
              for logs run: kubectl -n kabanero logs java-microprofile-manual-pipeline-run-image-scan-task-cdvbs-pod-b135f6
              -c step-mount-image'
            reason: Failed
            status: "False"
            type: Succeeded
          podName: java-microprofile-manual-pipeline-run-image-scan-task-cdvbs-pod-b135f6
          startTime: "2019-11-05T13:50:31Z"
          steps:
          - container: step-mount-image
            imageID: docker.io/appsody/appsody-buildah@sha256:4a9941d67464af5594eddf0b3e816fbb6ac6164fa2d27d269cbaa6ab6f3f3eb1
            name: mount-image
            terminated:
              containerID: cri-o://87d28346e93bd53f3ce2b0384318218fa3ca424c858b371639ce7e7822012fe9
              exitCode: 2
              finishedAt: "2019-11-05T13:51:05Z"
              reason: Error
              startedAt: "2019-11-05T13:50:46Z"
          - container: step-scan-image
            imageID: docker.io/kabanero/scanner@sha256:57910b551275b26dfd8e77150b1287836ad0ef1662568cca1c6c32ce4fb3c1b3
            name: scan-image
            terminated:
              containerID: cri-o://fe1db54a70bcb79eeb5c1de0cd561b454b41dcc4c56188c5d77cf742a9d15f55
              exitCode: 0
              finishedAt: "2019-11-05T13:51:05Z"
              reason: Completed
              startedAt: "2019-11-05T13:51:01Z"
          - container: step-git-source-git-source-8h2v9
            imageID: quay.io/openshift-pipeline/tektoncd-pipeline-git-init@sha256:b9beb1d9e41e08923f6683467dae01bb1657fdbae2e19f08c4c866f26eef3e0d
            name: git-source-git-source-8h2v9
            terminated:
              containerID: cri-o://642fb7cde1f86e9eb70104636cd894724f225c378ac76fe4ef7896c7c6530e0f
              exitCode: 0
              finishedAt: "2019-11-05T13:51:05Z"
              reason: Completed
              startedAt: "2019-11-05T13:50:43Z"
oc logs java-microprofile-manual-pipeline-run-image-scan-task-cdvbs-pod-b135f6 --all-containers=true
{"level":"warn","ts":1572961841.9309406,"logger":"fallback-logger","caller":"logging/config.go:69","msg":"Fetch GitHub commit ID from kodata failed: \"KO_DATA_PATH\" does not exist or is empty"}
{"level":"info","ts":1572961841.9319112,"logger":"fallback-logger","caller":"creds-init/main.go:40","msg":"Credentials initialized."}
{"level":"warn","ts":1572961863.871822,"logger":"fallback-logger","caller":"logging/config.go:69","msg":"Fetch GitHub commit ID from kodata failed: \"KO_DATA_PATH\" does not exist or is empty"}
{"level":"info","ts":1572961865.2931924,"logger":"fallback-logger","caller":"git/git.go:102","msg":"Successfully cloned https://github.com/dacleyra/appsody-hello-world/ @ master in path /workspace/git-source"}
Error initializing source docker://image-registry.openshift-image-registry.svc:5000/kabanero/java-microprofile:latest: pinging docker registry returned: Get https://image-registry.openshift-image-registry.svc:5000/v2/: x509: certificate signed by unknown authority
total 4
drwxrwxrwx. 5 root root 87 Nov  5 13:51 .
drwxr-xr-x. 4 root root 31 Nov  5 13:50 ..
drwxr-xr-x. 2 root root 25 Nov  5 13:50 .docker
-rw-------. 1 root root  0 Nov  5 13:50 .git-credentials
-rw-------. 1 root root 29 Nov  5 13:50 .gitconfig
drwxr-----. 3 root root 19 Nov  5 13:51 .pki
drwxr-xr-x. 2 root root 39 Nov  5 13:50 .ssh
cp: missing destination file operand after '/var/lib/containers'
Try 'cp --help' for more information.
ls: cannot access '/var/lib/containers/merged': No such file or directory

@dacleyra - Hi Dan is this bug related to release 0.3.0?

yes, adding tag

@aadeshpa can you fill out your GitHub profile so that I can find your id when assigning defects please? :)   Since your ID is aadeshpa typing ashish does not bring up your id. :)

I've assigned @teddyjtorres to diagnose but may need help from the pipeline team.

for now we added tls-verify=false like we do in other places to get us past this issue.  have another issue to deal with documenting cert setup for users who would prefer doing that.  the fix for this is part of the larger scan task fix I will be creating a PR for shortly.

@kvijai82 Where would the fix go? In collections? Do we expect new collections release?

@aadeshpa can you fill out your GitHub profile so that I can find your id when assigning defects please? :) Since your ID is aadeshpa typing ashish does not bring up your id. :) . Same for @kvijai82 ... please add your name to your profile.

@stephenkinder : updated the name in the profile. Now I think you would be able to search us with name.

@mtamboli yes I am in the process of pushing the fix to collections right now.  we will need a respin of the collections to pick it up.

@kvijai82 @marikaj123 Please let me know when the PR needs review and I can review then I can cut a 0.3.0.-rc.3 release (if that is what is required).

Fix should be in the new collections release.  @mtamboli / @dacleyra could you please verify & close this issue when you get a chance?  Thanks!

@kvijai82  It seems to be working fine. Do you expect image scanning to happen after deployment?

In this pipeline, the deploy task & scan task run in parallel.  The thinking right now is that the scan results would be reviewed by a human as there are some false positive results that can happen.
When run via the eventing framework, this task is called in a pipeline that is driven only when a PR is merged.  The results can then be reviewed by the team and when they create a release in the git repo, the deploy pipeline will run.

Closing this issue as @mtamboli validated the task passes now.


Custom SQL queries should use new JSON ?_extra= format

Related:

#262

I've made the change to the table view, now I need the new format to work for arbitrary SQL queries too.
Note that this incorporates both arbitrary SQL queries and canned queries.

[ ] Read queries with .json
[ ] Read queries HTML
[ ] Read queries other formats
[ ] Write queries (a canned query thing)

As part of this I should be able to figure out which bits of the new code I wrote for the table view should actually be shared with the query view. That stuff is mostly going to be from this commit: https://github.com/simonw/datasette/commit/d97e82df3c8a3f2e97038d7080167be9bb74a68d
Here's the existing QueryView class I need to replace:
https://github.com/simonw/datasette/blob/4c1e277edbd783d06840d3f9b20bf00783478ce4/datasette/views/database.py#L215-L532

I'd really like to refactor all of the extras functions into a datasette/extras.py module. The table ones currently rely a LOT on local variables in scope though, so I would need to rewrite those such that EVERY dependency they take is passed to asyncinject explicitly.

The default representation here can be even smaller.
For rows it's this:
{
  "ok": true,
  "next": "d,v",
  "rows": [...]
}

For SQL queries I'm considering this:
{
  "ok": true,
  "rows": [...]
}

I considered adding "sql" and "params" too, but on further thought those would be entirely a waste of bytes the majority of the time. If a user wants those they can request them with an ?_extra=query as seen here:
http://localhost:8001/content/releases.json?_size=0&_extra=query
{
  "ok": true,
  "next": null,
  "query": {
    "sql": "select html_url, id, author, node_id, tag_name, target_commitish, name, draft, prerelease, created_at, published_at, body, repo, reactions, mentions_count from releases order by id limit 1",
    "params": {}
  },
  "rows": []
}


CUDA out of memory when quantizing LLaMA-70b

I tried to quantize llama-70b model on a machine with 8 A100 GPUs, but CUDA OOM error occured (while llama-13b can be quantized successfully). How to quantize such large models with AutoAWQ? Is there some extra params concerning parallelism should be added when loading the model? Thanks!

Hi @Enjia, very sorry to hear that. Could you try #66? I have improved model loading. Additionally, you should try experimenting with passing the following argument:
model = AutoAWQForCausalLM.from_pretrained(model_path, **dict(low_cpu_mem_usage=True))

@casper-hansen Thank you so much for your revision. I managed to quantize llama-70b into using awq. FIY, "low_cpu_mem_usage=True" of function AutoModelForCausalLM.from_pretrained() in base.py is redundant.


Fixed #26686 -- Fixed crash when registering model signals with abstract senders

#26686

Looks okay, have you thought about whether adding a test is feasible?

Yeah, I could add a test that models passed as senders get registered immediately, whereas string references get passed to _lazy_model_operation. I'll update soon.
What do you think about the abstract senders question in general?
Also, would it be possible to backport the disconnect() fix in https://github.com/django/django/commit/ff6c6feae17120c2c7df74fb6a9dc76826a1e233 to 1.10 from master so this patch can apply to both?

I've added a test.

merged in 08014fe75b4fc379523f340191a02147ec35f7a3, thanks!

Thanks for going ahead and making those changes Tim, all fine with me. 👍


Use Auth0

I wanted to remove Identity Server and replace it with an Auth0 or similar OAuth provider. It would remove many of the docker-compose that creates a hard time to get started with the project.
What do you think?

Maybe looking into SimpleIdServer.OAuth ?

Hi, are you still accepting PR's to add some new functionality? I am thinking of add new features to this repo.

Hey @umer322!
We could accept all kind of PRs (bugfixes, improvements, new features).
I am a bit hands off since I got a kid but I am open to review and discuss ideas!
Sorry if I missed any message about this repo. If it was important just hit me again to bring it to top.
Best!


review/final-adjustments

@fivetran-avinash thank you for your hard work on these updates! I have been able to make some final review notes and made the adjustments within this PR for easier merging into your branch and for release.
One major change here is that you will notice I actually ended up removing the *_ending_date variables. As I was testing the incremental logic it really became apparent that ending variables do not make sense for incremental models. As there won't be any incremental merges if the end variable is set. This would then require the user to disable the variable and I would prefer they don't need to worry about handling these variables after deployment. I know I thought it would be a good addition, but after testing the incremental strategy further and seeing how it didn't click, I opted to remove it. Let me know if you disagree.
Additionally, I was able to clean up the date spine logic quite significantly. I was noticing that with all this logic the runtime of the model and incremental runs was taking quite a lot of time. Upwards of 15 minutes for just a few days 😨. Therefore, I opted to go for a much more streamlined approach that still gets the job done. We avoid the greatest function because that was causing the runtime to explode. It would have been a nice feature to include, but when testing this out I could see how it was making the model less performant and I would rather we just set a default date and then let the variables do their thing. I called this out in the README section and also removed the ending variables from the README. I appreciate your hard work in trying to get the greatest function to work. Again, I would love if we could do this but it just doesn't seem possible within the use case we are trying to provide in this feature.
I made some other small documentation adjustments. Please let me know if this makes sense to you or if you have any questions. I am happy to dive into my updates. Especially within the incremental logic. I noticed when testing the incremental logic in this latest update that it was not working as expected. In the end, simplifying the code for the date spine really helped to ensure the incremental logic works as expected.
Also neat finding on my end, I didn't realize you can nest variables and default configs like the below! This is something I will definitely want to use in the future!
var('account_history_start_date', var('global_history_start_date', '2016-01-01'))

@fivetran-joemarkiewicz After testing and validation, all the new logic looked good to me!


The reason of inserting strings to text in _convert_to_str

Hi, could you explain the reason of inserting strings !@#$%^&* to the original text in _convert_to_str?
https://github.com/McGill-NLP/llm2vec/blob/main/llm2vec/llm2vec.py#L254
    def _convert_to_str(self, instruction, text):
        # ...
        return f"{instruction.strip()} !@#$%^&*(){text}"

Hi,
Sure. Following other concurrent work recipe, we only take the representation of the input text during the pooling. In other words, the instruction tokens affect the representation of the input text (e.g., queries), and in the pooling step, we only take the representation of the input text into account.
Therefore, we add a special separator so that in the tokenize function we can define an embed_mask so we mask out the instruction tokens flawlessly when pooling.
Please let us know if you need more explanation on this.

Thanks! That makes sense.


Property illuminance not available in pypi library

Problem
The version of this library installed with pip does not includes the property illuminance from core.py.
Tested in multiple reTerminals.
Steps to reproduce it

Install the library as per official instructions: sudo pip3 install seeed-python-reterminal

Start a python shell, import the module and try to read illuminance data:

import seeed_python_reterminal.core as rt
print(rt.illuminance)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: '_Core' object has no attribute 'illuminance'

Potential solution
The library version in pypi is 0.2, published on May 20. 2021, and matches the version 0.2 in setup.py of this repo.
The illuminance property and example were added on June 15, 2021. Uploading a new version 0.3 to pypi might be necessary.
Workaround

Find library installation path with pip3 show seeed-python-reterminal. Look for Location:  path.
Go to library installation folder and open core.py with CLI editor of choice (eg. nano, vim, etc).
Manually add the two missing lines to core.py, match code in the main branch.

   __LIGHT_ILLUMINANCE = "/sys/bus/iio/devices/iio:device0/in_illuminance_input"

  @property
    def illuminance(self):
        return int(self.__read_1st_line_from_file(_Core.__LIGHT_ILLUMINANCE))

Hi @maujac ,
Thanks for report with detail.
You are right.
Ask the person in charge to release the latest code to PyPI.

@matsujirushi @maujac It's done.
https://pypi.org/project/seeed-python-reterminal/


how to refresh ui-select-match

Here the example:
http://plnkr.co/edit/xGrIa9R8uQDx8Qmx2dbd?p=preview
when on-select changed to 'Adam', ui-select-match show<EMAIL_ADDRESS>not<EMAIL_ADDRESS>

Having quite the same question here. I'm currently editing an item from a modale window, update the item itself (the ngModel remains the same, only displayed text is updated), but I can't find any way to update the ui-select-match value that's now out of sync. If anyone ( @zengchuan ?) has any solution or workaround ? I couldn't find anything so far.

Demonstration using the refresh attribute: http://plnkr.co/edit/YCdcjzYGeHC1g5vGF9QX?p=preview
Closing as a support issue.


[Bug] Subgraph stuck forever after (falsly?) detecting a reorg

Bug report
This bug report is related to #5101, but involves a at least one important difference - no reorg!
Multiple copies of the same subgraph (against different deployments of the same set of contracts) are deployed to a node running locally. Anvil is providing RPC and it is not instructed to perform (nor it performs to the best of my knowledge) any reorgs. At some point, graph-node detects the reorg. Whole setup is running inside a docker-compose.
This bug is rather repeatable. More subgraphs is deployed, the higher is the chance of seeing it. More load on the machine leads to more frequent occurances.
Log below was redacted to be of reasonable size (original had 2.5mln of lines). I've removed lines mentioning all but two subgraphs, sections where logs were repeated in a loop, messages with following substrings:

Committed write batch
Done processing trigger
Contract call reverted
Call to getCurrentEpoch

I've observed this bug with both v0.34.1 and v0.35.1.
Relevant log output
Aug 05 12:03:56.060 INFO Graph Node version: 0.34.1 (2024-02-08)
Aug 05 12:03:56.060 WARN GRAPH_POI_ACCESS_TOKEN not set; might leak POIs to the public via GraphQL
Aug 05 12:03:56.060 INFO Generating configuration from command line arguments
Aug 05 12:03:56.060 WARN No fork base URL specified, subgraph forking is disabled
Aug 05 12:03:56.060 INFO Starting up
Aug 05 12:03:56.060 INFO Trying IPFS node at: http://ipfs:5001/
Aug 05 12:03:56.072 INFO Successfully connected to IPFS node at: http://ipfs:5001/
Aug 05 12:03:56.075 INFO Creating transport, capabilities: archive, traces, url: http://anvil:8545, provider: localhost-rpc-0
Aug 05 12:03:56.080 WARN Expensive queries file not set to a valid file: /etc/graph-node/expensive-queries.txt
Aug 05 12:03:56.093 INFO Connecting to Postgres, weight: 1, conn_pool_size: 10, url: postgresql://graph-node:HIDDEN_PASSWORD@graph-postgres:5432/graph-node?sslmode=prefer, pool: main, shard: primary
Aug 05 12:03:56.094 INFO Pool successfully connected to Postgres, pool: main, shard: primary, component: Store
Aug 05 12:03:56.098 INFO Setting up fdw, pool: main, shard: primary, component: ConnectionPool
Aug 05 12:03:56.105 INFO Running migrations, pool: main, shard: primary, component: ConnectionPool
Aug 05 12:03:56.454 INFO Migrations finished, pool: main, shard: primary, component: ConnectionPool
Aug 05 12:03:56.455 INFO Mapping primary, pool: main, shard: primary, component: ConnectionPool
Aug 05 12:03:56.459 INFO Mapping primary, pool: main, shard: primary, component: ConnectionPool
Aug 05 12:03:56.479 INFO Connecting to Ethereum to get network identifier, capabilities: archive, traces, provider: localhost-rpc-0
Aug 05 12:03:56.480 INFO Connected to Ethereum, capabilities: archive, traces, network_version: 1337, provider: localhost-rpc-0
Aug 05 12:03:56.497 INFO Creating LoadManager in disabled mode, component: LoadManager
Aug 05 12:03:56.497 INFO Started block ingestor, network_name: localhost
Aug 05 12:03:56.497 INFO Starting block ingestor for network, network_name: localhost
Aug 05 12:03:56.497 INFO Starting job runner with 5 jobs, component: JobRunner
Aug 05 12:03:56.497 INFO Starting JSON-RPC admin server at: http://localhost:8020, component: JsonRpcServer
Aug 05 12:03:56.497 INFO Starting GraphQL HTTP server at: http://localhost:8000, component: GraphQLServer
Aug 05 12:03:56.497 INFO Started all assigned subgraphs, node_id: default, count: 0, component: SubgraphRegistrar
Aug 05 12:03:56.498 INFO Starting index node server at: http://localhost:8030, component: IndexNodeServer
Aug 05 12:03:56.498 INFO Starting metrics server at: http://localhost:8040, component: MetricsServer
Aug 05 12:03:56.498 INFO Starting GraphQL WebSocket server at: ws://localhost:8001, component: SubscriptionServer
Aug 05 12:03:56.498 INFO Downloading latest blocks from Ethereum, this may take a few minutes..., provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:04:30.589 INFO Syncing 19 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 19, blocks_behind: 19, latest_block_head: 19, current_block_head: 0, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:04:40.412 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_ntQyCN") }, component: JsonRpcServer
Aug 05 12:04:51.703 INFO Syncing 9 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 9, blocks_behind: 9, latest_block_head: 28, current_block_head: 19, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:04:54.727 INFO Syncing 10 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 10, blocks_behind: 10, latest_block_head: 38, current_block_head: 28, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:04:55.760 INFO Syncing 9 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 9, blocks_behind: 9, latest_block_head: 47, current_block_head: 38, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:05:05.512 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_qWI4L4") }, component: JsonRpcServer
Aug 05 12:05:16.830 INFO Syncing 7 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 7, blocks_behind: 7, latest_block_head: 54, current_block_head: 47, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:05:20.867 INFO Syncing 19 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 19, blocks_behind: 19, latest_block_head: 73, current_block_head: 54, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:05:31.934 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_m84HKa") }, component: JsonRpcServer
Aug 05 12:05:52.006 INFO Syncing 4 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 4, blocks_behind: 4, latest_block_head: 77, current_block_head: 73, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:05:53.029 INFO Syncing 15 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 15, blocks_behind: 15, latest_block_head: 92, current_block_head: 77, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:06:03.970 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_x7hO46") }, component: JsonRpcServer
Aug 05 12:06:16.131 INFO Syncing 7 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 7, blocks_behind: 7, latest_block_head: 99, current_block_head: 92, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:06:17.162 INFO Syncing 2 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 2, blocks_behind: 2, latest_block_head: 101, current_block_head: 99, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:06:18.177 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 102, current_block_head: 101, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:06:22.191 INFO Syncing 19 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 19, blocks_behind: 19, latest_block_head: 121, current_block_head: 102, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:06:34.273 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_0vdwLp") }, component: JsonRpcServer
Aug 05 12:06:45.292 INFO Syncing 5 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 5, blocks_behind: 5, latest_block_head: 126, current_block_head: 121, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:06:48.310 INFO Syncing 19 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 19, blocks_behind: 19, latest_block_head: 145, current_block_head: 126, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:06:59.163 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_rJsjIb") }, component: JsonRpcServer
Aug 05 12:07:11.408 INFO Syncing 14 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 14, blocks_behind: 14, latest_block_head: 159, current_block_head: 145, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:07:12.467 INFO Syncing 5 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 5, blocks_behind: 5, latest_block_head: 164, current_block_head: 159, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:07:22.062 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_nC7XTw") }, component: JsonRpcServer
Aug 05 12:07:32.524 INFO Syncing 7 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 7, blocks_behind: 7, latest_block_head: 171, current_block_head: 164, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:07:35.549 INFO Syncing 19 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 19, blocks_behind: 19, latest_block_head: 190, current_block_head: 171, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:07:46.876 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_UHlAQ7") }, component: JsonRpcServer
Aug 05 12:07:57.658 INFO Syncing 5 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 5, blocks_behind: 5, latest_block_head: 195, current_block_head: 190, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:00.677 INFO Syncing 10 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 10, blocks_behind: 10, latest_block_head: 205, current_block_head: 195, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:01.708 INFO Syncing 9 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 9, blocks_behind: 9, latest_block_head: 214, current_block_head: 205, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:12.172 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_CH3Fsu") }, component: JsonRpcServer
Aug 05 12:08:21.772 INFO Syncing 3 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 3, blocks_behind: 3, latest_block_head: 217, current_block_head: 214, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:22.786 INFO Syncing 6 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 6, blocks_behind: 6, latest_block_head: 223, current_block_head: 217, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:25.807 INFO Syncing 19 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 19, blocks_behind: 19, latest_block_head: 242, current_block_head: 223, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:37.031 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_tJyvJN") }, component: JsonRpcServer
Aug 05 12:08:46.137 INFO Received subgraph_deploy request, params: SubgraphDeployParams { name: SubgraphName("octant_test_tJyvJN"), ipfs_hash: DeploymentHash("QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt"), node_id: None, debug_fork: None, history_blocks: None }, component: JsonRpcServer
Aug 05 12:08:46.140 INFO Set subgraph start block, block: None, sgd: 0, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphRegistrar
Aug 05 12:08:46.140 INFO Graft base, block: None, base: None, sgd: 0, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphRegistrar
Aug 05 12:08:46.721 INFO Resolve subgraph files using IPFS, n_templates: 0, n_data_sources: 4, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:46.721 INFO Successfully resolved subgraph files using IPFS, features: ø, n_templates: 0, n_data_sources: 4, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:46.723 INFO Starting subgraph writer, queue_size: 5, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:46.731 INFO Data source count at start: 4, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:46.784 INFO Scanning blocks [0, 0], range_size: 1, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:08:46.787 INFO Applying 1 entity operation(s), block_hash: 0x4657810184697a7dc6d140e376f12c576aec6086962c671e661de57ee0cb0fb9, block_number: 0, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:47.163 INFO Applying 2 entity operation(s), block_hash: 0x51e616e7bcf4a68be42e173c45fca193d946bcb5e131443cf855b6362b18d6e5, block_number: 228, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:47.183 INFO Applying 3 entity operation(s), block_hash: 0x1f94f6f512fea2bff03bbe1b71bb441ce78d9179243f2fab320cf3ca8a3db0b3, block_number: 240, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:47.900 INFO Syncing 6 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 6, blocks_behind: 6, latest_block_head: 248, current_block_head: 242, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:48.451 INFO Applying 4 entity operation(s), block_hash: 0x782768aabf1016a47cfead315ab893dfca9999e818826e0ac26b480719c9c7e5, block_number: 248, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:48.915 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 249, current_block_head: 248, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:49.434 INFO Applying 2 entity operation(s), block_hash: 0x0c214fca6cc708e09e20c5b2ee0c775ed131b232876113aacb79f095970cc649, block_number: 249, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:08:51.923 INFO Syncing 11 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 11, blocks_behind: 11, latest_block_head: 260, current_block_head: 249, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:08:52.967 INFO Syncing 6 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 6, blocks_behind: 6, latest_block_head: 266, current_block_head: 260, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:09:02.272 INFO Received subgraph_create request, params: SubgraphCreateParams { name: SubgraphName("octant_test_m1OoKI") }, component: JsonRpcServer
Aug 05 12:09:13.031 INFO Syncing 7 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 7, blocks_behind: 7, latest_block_head: 273, current_block_head: 266, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:09:13.606 INFO Applying 2 entity operation(s), block_hash: 0xc1c59edc6729ea3eb8e302690480bfb996e1c0fd75a3f351bfcfcb2b409655f0, block_number: 273, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:14.048 INFO Syncing 1 blocks from Ethereum, code: BlockIngestionStatus, blocks_needed: 1, blocks_behind: 1, latest_block_head: 274, current_block_head: 273, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:09:14.565 INFO Applying 2 entity operation(s), block_hash: 0x058339e9953ec14f8070e51091ac5704d8f5ceec7708e6b7f28b031cb82fb4fd, block_number: 274, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:17.056 INFO Syncing 16 blocks from Ethereum, code: BlockIngestionLagging, blocks_needed: 16, blocks_behind: 16, latest_block_head: 290, current_block_head: 274, provider: localhost-rpc-0, component: EthereumPollingBlockIngestor
Aug 05 12:09:17.606 INFO Reverting block to get back to main chain, revert_to_ptr: #273 (c1c59edc6729ea3eb8e302690480bfb996e1c0fd75a3f351bfcfcb2b409655f0), subgraph_ptr: #274 (058339e9953ec14f8070e51091ac5704d8f5ceec7708e6b7f28b031cb82fb4fd), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:17.629 INFO Reverting block to get back to main chain, revert_to_ptr: #272 (a206f5eddb5d29551e2d2c2136d7e1d17b092f7faac93d1fb08f366592171fc0), subgraph_ptr: #273 (c1c59edc6729ea3eb8e302690480bfb996e1c0fd75a3f351bfcfcb2b409655f0), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:18.621 INFO Reverting block to get back to main chain, revert_to_ptr: #217 (77e5a5b7376f8a6218e181632774379282346ee26abf2b8db942e58a1b776585), subgraph_ptr: #218 (ba522f62057a9947f4a8b06bfa1a0e1cdc784c71c333f1843973226ab17e143f), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:18.637 INFO Reverting block to get back to main chain, revert_to_ptr: #216 (f9a810abc3da477559dced2db76502c5d716e65ebc238f65c2d31ca89cb30546), subgraph_ptr: #217 (77e5a5b7376f8a6218e181632774379282346ee26abf2b8db942e58a1b776585), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:18.653 INFO Reverting block to get back to main chain, revert_to_ptr: #215 (b4eb938b80a6660610920f43349dcbfb00a7d049a2fb963ddd2fba2915d05039), subgraph_ptr: #216 (f9a810abc3da477559dced2db76502c5d716e65ebc238f65c2d31ca89cb30546), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:18.663 INFO Reverting block to get back to main chain, revert_to_ptr: #214 (7113a9e1e1fb65015a1629932fa817c4ef3dd732a9dec81d405e4088ba938860), subgraph_ptr: #215 (b4eb938b80a6660610920f43349dcbfb00a7d049a2fb963ddd2fba2915d05039), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:18.689 INFO Reverting block to get back to main chain, revert_to_ptr: #213 (2e7980beecae1ebed5e83c2b175bf6f58274bd4bfc47b9ca9371c773c7797bf8), subgraph_ptr: #214 (7113a9e1e1fb65015a1629932fa817c4ef3dd732a9dec81d405e4088ba938860), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:18.706 INFO Reverting block to get back to main chain, revert_to_ptr: #212 (07c05ab5d8549240122d75116c00a518b870452c43caa761fb1cf41d4fa8fc31), subgraph_ptr: #213 (2e7980beecae1ebed5e83c2b175bf6f58274bd4bfc47b9ca9371c773c7797bf8), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.847 INFO Reverting block to get back to main chain, revert_to_ptr: #46 (61e9db94e2081e7b541ac197b7f3873d7f1c042efc4111f9ea3e0449f7d3b786), subgraph_ptr: #47 (75dd5e9809a02288ca5fd70c6dbd5cfb76cbb3c66f363474cdb938daa42d5f54), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.863 INFO Reverting block to get back to main chain, revert_to_ptr: #45 (094759e1352336b8f418b4cf8c88a6bedd11bccf03bcc1d92e3fafcef2c43199), subgraph_ptr: #46 (61e9db94e2081e7b541ac197b7f3873d7f1c042efc4111f9ea3e0449f7d3b786), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.884 INFO Reverting block to get back to main chain, revert_to_ptr: #44 (021a4490b3d46abe48f96f3a2c0abbdb773f34ec8965e9befcb075cf0f60096f), subgraph_ptr: #45 (094759e1352336b8f418b4cf8c88a6bedd11bccf03bcc1d92e3fafcef2c43199), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.905 INFO Reverting block to get back to main chain, revert_to_ptr: #43 (3ef6b2eee589f036ff02489e2ecb5b4b35af8e7ce171cad83d985c1b5f083aa1), subgraph_ptr: #44 (021a4490b3d46abe48f96f3a2c0abbdb773f34ec8965e9befcb075cf0f60096f), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.920 INFO Reverting block to get back to main chain, revert_to_ptr: #42 (b608701a2f8aa6b9f8adbe6e914de4b10c2cd42bac7cdcb0c4838804131e50af), subgraph_ptr: #43 (3ef6b2eee589f036ff02489e2ecb5b4b35af8e7ce171cad83d985c1b5f083aa1), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.941 INFO Reverting block to get back to main chain, revert_to_ptr: #41 (eef114c50ab517b197c1c904fdfb4dd52400e1eb8961ba4cbe4a531017b25c00), subgraph_ptr: #42 (b608701a2f8aa6b9f8adbe6e914de4b10c2cd42bac7cdcb0c4838804131e50af), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.960 INFO Reverting block to get back to main chain, revert_to_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), subgraph_ptr: #41 (eef114c50ab517b197c1c904fdfb4dd52400e1eb8961ba4cbe4a531017b25c00), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.981 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:21.982 INFO Scanning blocks [40, 40], range_size: 10, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:09:22.019 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:22.021 INFO Scanning blocks [40, 40], range_size: 100, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:09:22.052 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:22.062 INFO Scanning blocks [40, 40], range_size: 1000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:09:22.091 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:09:22.101 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:22.134 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:22.140 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:09:22.168 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:22.170 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:09:22.204 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:09:22.211 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:23.915 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:23.943 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:23.953 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:23.987 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:23.996 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.032 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.034 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:24.064 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:24.069 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.281 INFO Scanning blocks [40, 40], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.320 INFO Reverting block to get back to main chain, revert_to_ptr: #39 (8a866e1b66b36df6092c336b150b0e75124b460293a78a02af13d60199f80cf8), subgraph_ptr: #40 (efb0d96faf3fb39334e625c9ab92175e560c24beffc36ffbe95b94e635e29608), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:24.360 INFO Scanning blocks [40, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.411 INFO Scanning blocks [48, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.449 INFO Scanning blocks [48, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.498 INFO Scanning blocks [48, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.553 INFO Scanning blocks [48, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:24.600 INFO Reverting block to get back to main chain, revert_to_ptr: #47 (75dd5e9809a02288ca5fd70c6dbd5cfb76cbb3c66f363474cdb938daa42d5f54), subgraph_ptr: #48 (176c8b512c90231e1c50f5e11fab56ec53a015421243622ed5bf049732e47334), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:24.602 INFO Scanning blocks [48, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:25.352 INFO Scanning blocks [48, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:25.403 INFO Scanning blocks [48, 48], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:25.403 INFO Reverting block to get back to main chain, revert_to_ptr: #47 (75dd5e9809a02288ca5fd70c6dbd5cfb76cbb3c66f363474cdb938daa42d5f54), subgraph_ptr: #48 (176c8b512c90231e1c50f5e11fab56ec53a015421243622ed5bf049732e47334), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:25.453 INFO Reverting block to get back to main chain, revert_to_ptr: #47 (75dd5e9809a02288ca5fd70c6dbd5cfb76cbb3c66f363474cdb938daa42d5f54), subgraph_ptr: #48 (176c8b512c90231e1c50f5e11fab56ec53a015421243622ed5bf049732e47334), sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: SubgraphInstanceManager
Aug 05 12:11:25.462 INFO Scanning blocks [48, 52], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:25.505 INFO Scanning blocks [52, 52], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream
Aug 05 12:11:25.542 INFO Scanning blocks [52, 52], range_size: 2000, sgd: 10, subgraph_id: QmaYtA9X9zi689TiGLxB2cyUZK2mWtkAwwL6D8VmhPDvdt, component: BlockStream

IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out

[ ] Tick this box if this bug is caused by a regression found in the latest release.
[ ] Tick this box if this bug is specific to the hosted service.
[X] I have searched the issue tracker to make sure this issue is not a duplicate.

OS information
Linux

A bit more information. We are using graph-node in Octant. We use self-hosted instance of graph-node on prod. One of automated testing environments deploys set of contracts and a subgraph per test. This is where we observe this behavior most often.


Push mandatory constraint on user attribute

From<EMAIL_ADDRESS>on August 23, 2010 11:30:00
Push mandatory constraint on user's attribute if this is mapped with a mandatory field of a target resource directly or indirectly associated to the user.
Original issue: http://code.google.com/p/syncope/issues/detail?id=37

From<EMAIL_ADDRESS>on August 30, 2010 02:33:06
Status: Started

From<EMAIL_ADDRESS>on August 30, 2010 02:35:10
Status: Fixed


not return a full list of limits

https://github.com/oracle-devrel/technology-engineering/tree/main/manageability-an[…]stom-metrics/custom-metric-python-SDK-services-limit-monitoring
Its helpful but it does not return a full list of limits. I did some debugging and I see that you call:
list_limit_definitions_response = limits_client.list_limit_definitions(
compartment_id = compartment_ocid,
  sort_by=“name”,
  sort_order=“ASC”)

that does not return all pages. To return all OCI limits I had to change them to
list_limit_definitions_response = oci.pagination.list_call_get_all_results(
  limits_client.list_limit_definitions,
  compartment_id = compartment_ocid,
  sort_by=“name”,
  sort_order=“ASC”)

and then I got all limits.

I created a PR with the new code. Needs to be tested now.

@NicolaCimitile @karthicgit Reminder - please have a look at this, and review my PR.


TS for sva is not working

Description
import { sva } from "../../../styled-system/css";

export const chipRecipe = sva({
  slots: ["root", "icon"],
  base: {
    root: {
      display: "flex",
      alignItems: "center",
      gap: "10px",
      width: "fit-content",
      height: "24px",
      paddingInline: "8px",
      borderRadius: "8px",
      cursor: "default",
    },
    icon: {
      width: "24px",
      height: "24px",
    },
  },
  variants: {
    view: {
      red: {
        root: {
          backgroundColor: "red",
        },
      },
    },
  },
});

panda config:
import { defineConfig } from "@pandacss/dev";

import { chipRecipe } from "./src/design-system/components/chip";

export default defineConfig({
  // Whether to use css reset
  preflight: true,

  // Where to look for your css declarations
  include: ["./src/**/*.{ts,tsx}"],

  // Files to exclude
  exclude: [],

  // Useful for theme customization
  theme: {
    extend: {
      slotRecipes: {
        chip: chipRecipe,
      },
    },
  },

  // The output directory for your css system
  outdir: "styled-system",
  outExtension: "js",
});

I get:

Link to Reproduction

Steps to reproduce

Go to '...'
Click on '...'
Scroll down to '...'
See error

JS Framework
No response
Panda CSS Version
0.11
Browser
No response
Operating System

[ ] macOS
[X] Windows
[ ] Linux

Additional Information
No response

There are also infinite reloads for solid-js project (SPA)

Thanks for raising this issue.
This shows we need to improve the docs somewhere.

sva is a function you use directly in your app. It generates atomic slot recipes.
defineSlotRecipe is the function to author slot recipes into the config.

In this case, replace sva with defineSlotRecipe and provide a className property as well.
t should work as expected.


Add supported BIG-IP/BIG-IQ versions to docs template

We should add a supported BIG-IP versions section to the docs template. This should also be added in to existing docs for F5-supported templates.
@pjbreaux and @jgruber have this information

Is this still an issue?

@mattgreene, I think so - the support matrix doesn't list which BIG-IP versions the templates are compatible with. I'm happy to take care of it, just need someone to provide the info.
@pjbreaux ? @jgruber ?


[WIP][ARCTIC-1000][AMS] Persist on the property of task after the update

Why are the changes needed?
fix #1000
Brief change log

persist the property of the task after updating the 'max-execute-time' when the task on executing

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before making a pull request

Documentation

Does this pull request introduces a new feature? (no)
If yes, how is the feature documented? (not documented)

cc @wangtaohz

It's not rigorous to update the 'max-execute-time' when the task on executing. Because we are unable to send it to Optimizer who is using this property to execute the task.

Yes, this only affects the next execution after updating the 'max-execute-time'. I don't think we need to stop the task once someone updates the self-optimizing.execute.timeout.


PDB_code

I noticed that these pdb_code were discarded when generating pdb_code, can you share the reason for doing so?
if pdb_code != "6g5i" and pdb_code != "5t0j" and pdb_code != "5wve":

rdkit can not process these PDBs so I excluded them from the graph generation.


Research of Authentification with the help of Github

Task:
Make a research of Authentification with the help of Github
So, the idea that your application would delegate authentification to third-party service
In our case, it's a Github
Provide the source code(on github) for any successful findings

Overview
Authentication is a process in which the credentials provided are compared to those on file in a database of authorized users' information on a local operating system or within an authentication server. If the credentials match, the process is completed and the user is granted authorization for access.
GitHub has API that can be used for authentication. To use it first you should register your application on GitHub.
OAuth2
OAuth2 is a protocol that lets external apps request authorization to private details in a user's GitHub account without getting their password. This is preferred over Basic Authentication because tokens can be limited to specific types of data, and can be revoked by users at any time. All developers need to register their application before getting started. A registered OAuth application is assigned a unique Client ID and Client Secret.
GitHub's OAuth implementation supports the standard authorization code grant type. This standard works like this:

(A)  The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint.  The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).
(B)  The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
(C)  Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration).  The redirection URI includes an
authorization code and any local state provided by the client
earlier.
(D)  The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step.  When making the request, the
client authenticates with the authorization server.  The client
includes the redirection URI used to obtain the authorization
code for verification.
(E)  The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C).  If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
Resources:

Authorization Code Grant
Other Authentication Methods
OAuth 2.0 простым и понятным языком

Authentication using JavaScript (no backend)
My first implementation of GitHub authentication is done with the help of JavaScript (just front-end).
The biggest disadvantage of this method is that when I send POST request from JavaScript, browser starts downloading file from response. And then you have to copy the text from that file manually.
When you do this, JS finds access token in that text and let you recieve information from GitHub.
This is very uncomfortable, so I've tried to find any information about this problem. But I couldn't find anything, so I've started a topic at stackoverflow and one of the solution is that using https instead of http may help, but I can't test it because I have only http.
Another solution is to use CORS, but you should setup it at GitHub server.
I uploaded this implementation on hosting - http://braga.fedyunin.com.ua/
You can also check it locally (but it won't work, because when I registered my application at github, I used http://braga.fedyunin.com.ua/ as application URL) here
Resources:

OAuth
Using CORS

Authentication using NodeJS-GitHub Api
There are more ways to communicate with GitHub using Node.JS module which provides an object oriented wrapper for the GitHub v3 API.
The best solution for me is JavaScript GitHub API for Node.JS. It provides clear functionality and has good documentation.
I registered another application on GitHub for this module. To check it, you can download all files from JavaScript GitHub API for Node.JS and replace test/oauth.js file with the file I uploaded here
Then if you open this file with the help of Node, you will be able to use GitHub authorization.
Resources:

octonode
JavaScript GitHub API for Node.JS

Authentication using Sinatra
Another way to make authentication with the help of GitHub is suggested by GitHub API documentation. But this method requires ruby to start the server and it's very similar to the previous method.
So I didn't add any code.
Resources:

GitHub Basics of Authentication

Conclusion
During my research I read how authentification works on GitHub.
First, you have to register your application to get Client ID and Client Secret key. When you get it, you can use GitHub API.
Among all the ways to use GitHub authentification that I found, I paid attention to 3 that I consieder to be the most useful.

Authentication using JavaScript is inconvinient but it works on client-side.
Authentication using NodeJS-GitHub Api is convinient and I think it's the best solution in our case
Authentication using Sinatra is recommended by GitHub documentation, but I couldn't test it, because it requires ruby and it's similar to the previous method


Add ratio vaccinated metric

Adds vaccinationsInitiatedRatio and vaccinationsCompletedRatio to metrics API fields

I'd be tempted to add these directly to OneRegionTimeseriesDataset instead of making a new module.

I'd be tempted to add these directly to OneRegionTimeseriesDataset instead of making a new module.

I'd be tempted to add these directly to OneRegionTimeseriesDataset instead of making a new module.

I'd rather add them to top_level_metrics.  I'm a bit time crunched for tonight, will look into this later

I'd be tempted to add these directly to OneRegionTimeseriesDataset instead of making a new module.

I'd rather add them to top_level_metrics.  I'm a bit time crunched for tonight, will look into this later


Capture price data

Capture price data from Amazon and Indigo from their webpage
Create a route to display price data in the front-end
Capture data for e-book and hardcopy

Price data successfully captured and route created


Install-Package IronPython Fails

Using Visual Studio 2019
Microsoft Visual Studio Community 2019
Version 16.1.4
VisualStudio.16.Release/16.1.4+29020.237
Microsoft .NET Framework
Version 4.7.03056
Installed Version: Community
PM> Install-Package IronPython
Restoring packages for C:\Users\Username\Source\Repos\IronPython\IronPython\IronPython.csproj...
Install-Package : NU1108: Cycle detected.
IronPython -> IronPython (>= 2.7.9).
At line:1 char:1

Install-Package IronPython

  + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
  + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

Install-Package : Package restore failed. Rolling back package changes for 'IronPython'.
At line:1 char:1

Install-Package IronPython

  + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
  + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

Time Elapsed: 00:00:00.4997431
PM> Install-Package IronPython.StdLib
Restoring packages for C:\Users\UserName\Source\Repos\IronPython\IronPython\IronPython.csproj...
Install-Package : NU1108: Cycle detected.
IronPython -> IronPython.StdLib 2.7.9 -> IronPython (>= 2.7.8 && < 3.0.0).
At line:1 char:1

Install-Package IronPython.StdLib

  + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
  + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

Install-Package : Package restore failed. Rolling back package changes for 'IronPython'.
At line:1 char:1

Install-Package IronPython.StdLib

  + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
  + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

Time Elapsed: 00:00:00.5412337
Install-Package IronPython -Version 2.7.9
fails as well

Ok turned out I had named the project IronPython, So when I created a new project with a different name it worked.


Researcher sees button to delete project

The researcher sees too many buttons, not just the delete button.


Docker healthcheck should exit early on error with apache/nginx/php-fpm

Is there an existing issue for this?

[X] I have searched the existing issues

Output of ddev debug test
Expand `ddev debug test` diagnostic information
[COPY-PASTE HERE THE OUTPUT OF `ddev debug test`]

Expected Behavior
The user should not wait two minutes for a timeout if something goes wrong with apache/nginx/php-fpm
Actual Behavior
If the container fails to become healthy on ddev start, the supervisor tries to restart apache/nginx/php-fpm until the 2 minute timeout. Previously, this led to early failure, but now we have a timeout.
The logic changed after

#5936

Steps To Reproduce
See:

https://github.com/ddev/ddev/issues/5899#issuecomment-2000105112

Anything else?
The issue is partially discussed in:

#5978

Thanks for opening the issue!


tests: coredump: Disable optimizations to prevent unexpected failures

debug.coredump.logging_backend is currently failing for most of the targets I have tried when building with clang. Depending on the target, func_3 invokes undefined behavior by dereferencing addr (which is NULL) which can lead to the compiler optimizing out significant portions of the code, resulting in unexpected/incorrect failures.
Here, clang seems to inline func_3 into main then marks the inlined implementation as unreachable (due to the UB) and removes it and everything after it in main. So, we fall through to whatever code lies past main, resulting in a test failure (timeout) from what I've seen. GCC seems to do similar things, but creates an invalid opcode instruction so the test still succeeds.
clang is correct in both optimizing this behavior out and leaving buggy code behind, so disable optimizations for func_3 to keep things under control and prevent the incorrect failures.

Just to add a bit more context/info, I tested this with an LLVM 16 build as well as a recent-ish build of LLVM's mainline. The test would timeout for me for the following boards when building with both versions of LLVM:

qemu_x86
qemu_cortex_a53 (using local changes to get this building correctly)
qemu_riscv32/qemu_riscv64 (using https://github.com/zephyrproject-rtos/zephyr/pull/68259)

The test seemed to work fine for the  qemu_cortex_m3 board + clang before this fix as clang would not optimize out the udf instruction. Clang also doesn't seem to optimize out the k_panic() call, but just adding __no_optimization seemed less invasive than forcing clang to always take that path.
With this change to the test, the test passes for all boards mentioned above for me locally.
The command I was using is as follows (with minor variations for the board, etc.):
west twister -W -p qemu_x86 -s tests/subsys/debug/coredump/debug.coredump.logging_backend -x=CONFIG_COMPILER_RT_RTLIB=y -x=CONFIG_LLVM_USE_LD=y -x=CONFIG_OUTPUT_DISASSEMBLY=y

The riscv32_virtual, hifive_unleashed, and hifive_unmatched boards apparently didn't like this change originally (they were timing out, please see the old CI logs for reference: https://github.com/zephyrproject-rtos/zephyr/actions/runs/8196145699/job/22415885346?pr=69939).
IIUC, these all seem to use Renode for simulation, so I think these boards match the comment about Call k_panic() directly so Renode doesn't pause execution and match what is discussed in https://github.com/zephyrproject-rtos/zephyr/pull/40434. As mentioned in the commit message above, GCC didn't seem to generate the null dereference previously (for RISC-V, it looks like it was generating an ebreak instruction) so it seems like these boards might have coincidentally worked previously?
To fix the CI issues, I added checks for these boards to have them take the k_panic() path. Please take another look and please let me know if there is another solution that would be prefereable!

Gentle ping


Feature/tutorial overlay

create the overlay and modal included for the tutorial
update Home and ShowImagePicker components

parameter isTutorial now added


[bazel/dbg copt] fix warning name for GCC

Reproduced with :

bazel-bootstrap 3.5.1+ds-3 (pulling bazel 6.4.0)
setting CC to gcc and CXX to g++ otherwise bazel does not detect it
overall, using debian 11 using default gcc/g++ versions 10.2.1

When using --config=dbg, a warning name produces an error at the beginning of the compilation :
cc1plus: error: '-Werror=return-stack-address': no option '-Wreturn-stack-address'; did you mean '-Wreturn-local-addr'?
Fixed the error following the compiler advice for GCC
PLEASE NOTE : I guess return-stack-address might be related to CLANG
and return-local-addr is the GCC equivalent. I do not know CLANG,
nor am i good enough with bazel to know how to make this option flexible
(so any help will be appreciated)

let's just remove this statement

We really don't want to mention warning flags in the bazel.rc file. This bazel.rc file is mostly for gRPC's own CI testing, and we already have a list of flags enabled through https://github.com/grpc/grpc/blob/master/bazel/copts.bzl. This file just mentions flags for clang but it gives us good CI coverage.

Included your feedback and removed the line.


Don't change ID when renaming/moving objects

Feature Request
Is your feature request related to a problem? Please describe.
I have a table with a foreign key that references the id column of the storage.objects table. But every time I rename an object (which results in a move) this link gets broken.
Describe the solution you'd like
Instead of deleting the old object in the database and inserting a new one, the existing object should be updated.

Hi @joeldomke,
This is an interesting scenario, conceptually objects are immutable. This is also the case in S3.
In S3 you cannot rename an object, you'll instead need to copy the object and assign a new name then delete the old one.
I'm wondering if in your case you might want to have the granular control and issue both commands on your end, so that you can update your link before the old object is deleted.
Do you think that might work for you?
The rename method does simply that in a single operation.

First of all sorry, I should have created a feature request in the supabase discussions section. That would have gotten more visibility and more opinions/insights from the community.
I think your suggestion would work if I renamed the images inside of my application. But since I'm currently working on a prototype I planned to use the storage file browser in supabase studio for now. But, whenever I rename/move something in the file browser I lose all my references.
Now that I know about the move behavior I just don't move anything, since I am working with a limited amount of files anyways.
For a more complex version with file renaming within the application, I would do the following:

Have an image table that has a reference to storage.objects.
Every time an object gets renamed I updated that reference in my images table.
Then, every table that needs to reference an image can reference my images table.

In order to update the id in my images table, I would need the ID of the object that was created during the move. It would be useful if the move method returned the ID just like the upload method does.

We have the same issue; since the storage schema does not have any metadata fields for users to use, we've ended up needing a relation table for objects just to store an object's related info.
When using move, this ID is broken, and in the case of using cascading, worse, it erases the data.

The more I've used the storage, the more Im convinced the Storage API needs to retain the same object ID and not change it for move/rename operations. Even if under the hood this is using S3, the API should abstract those details from the user and give a permanent reference to the "same" file from the supabase side. If the current id comes from S3, you could keep it as well in teh table un a new field or under the current metadata object, although that as well I think is just a dump of the S3 file metadata so merging that could pollute its integrity, I would store it in a new column called "s3_key_id" or something.

Hi, this is now fixed, and we do not change the id of a moved object


Scrollbars captured in mobile emulation - issue/feature request

This extension is an enormous help, thank you. I have just one issue with it - it captures the scrollbar multiple times in the screenshot, especially when viewing a page in 'mobile emulation' mode in Chrome.
From what I can tell, the mobile scrollbar appears in chrome when you scroll, then fades away a couple of seconds later. Would there be any chance of offering a config option to set a time delay before capturing each snapshot as the page scrolls down please? It looks like somewhere in the region of ~2 seconds would do the trick.
thank you very much for an awesome extension.

Hi @Taymar thanks for the reminder on this. I’ve looked into a number of solutions and it’s surprisingly hard to force the mobile emulator to hide the scroll bars. Maybe the longer time delay is the best I can do. I’ll take a look at this.

@mrcoles Thanks ever so much! I'm no developer but can absolutely appreciate that hiding part of the browser UI doesn't sound like a simple task. Even an extra field in the options where one could specify the time delay would be fantastic.
Thanks again :)


Sync not work on ios

I use this plugin a long time, and it's always work on pc
About two to three months ago, on my iPad, Obsidian would crash upon opening as long as this plugin was installed.
Additionally, about half a month ago, I encountered the same issue on my iPhone. So, I deleted the Obsidian app on my iPhone and reinstalled the app and the plugin. However, since then, abot half of MD files I cann't sync to the repository, and even using Fetch, I can't retrieve the full repository data anymore.
I haven't seen many logs, only the one in the screenshot. I'm not sure if it can provide any help.

Sorry for your inconvenience and thank you so much for opening this issue.
Would you please check if the LiveSync data has been synchronised using Pick a file to show history?
If the data is simply synchronised but not realised in storage, some files will be shown in the list.
This behaviour sometimes occurs, especially in mobile devices when the device has slept and the replication and fetching chunks are cancelled.
If some missing files are shown, I am sorry to have to ask you to do this, could you please try Fetch again with the vault that already synchronised half, and keep awake the device?

Hi,I am sorry about I cant find the “ Pick a file to show history”, would u like give me some hint?

@Porco24 thats in the command palette

@Sirtz Thanks your so much, I found it now
@vrtmrz
I used "Pick a file to show history" and found that the files have not been synchronized.
And I tried to Fetch again, I get this error

@Porco24
Thank you for confirming this! Hmmm. Does the replication error also appear on other devices?

@vrtmrz
Hi,
I've never had any issues syncing between my home and office computers, but a few months ago, my iPad suddenly stopped updating without any error messages. Later, when I opened Obsidian on my iPad, the app would first display some sync plugin logs with content I can't remember, then show a loading progress bar before crashing. Recently, I tried uninstalling Obsidian from my iPad and syncing the repository again using the sync plugin. However, it encountered a problem similar to what I'm experiencing on my iPhone, where not all files have been synchronized. When I try to fetch, there are only logs saying "Hidden files and plugin synchronization have been temporarily disabled" and "All synchronization have been temporarily disabled", with no progress indication afterwards.
The issue I'm facing on my iPhone is quite similar to that on my iPad. If there were more log outputs, perhaps I could be of more assistance.

Thank you for checking things!
I am wondering why it has crashed in this case. One of that had been caused by Out-Of-Memory on Plugin and their settings, And it has been refined as Customization sync at v0.19.0.
If you enabled this feature, would you mind if I ask you to try the latest version?
If it does not work well, possibly rebuilding is needed.
May we ask if other devices have been synchronised?

Yes, I had enable sync Plugin, and I had try Customization sync at v0.19.0.
It's still have the "replication error" when I open this setting and fetch again
My other pc devices is alwasy been synchronised

Thank you for the detail! I am still wondering why it has been broken only on iOS.
Could you please try enabling a verbose log? Some more information will be shown in the log pane.
And, if you do not mind, it would be helpful if you could paste the report which can be made in the Hatch pane.

@vrtmrz
When I replied earlier, I had actually already turned on the verbose log, and it's didn't have more infomation.
And, about paste the report, I've redacted some personal information and attached it in the file.
log.txt

@Porco24 Oh, my apologies for that! I was inadvertent.
Thank you for the configuration! I made the same configuration and try to initialise - replicate and fetch between an iOS and a Windows device. However, contrary to my expectations, it succeeded.
I hope to investigate it more. Let me ask something.

Messages which you have seen mean that the plug-in tried to fetch. Following this, (I hope that) you should see Local Database Reset, Mark this device as resolved  and Replication activated. Have you seen them?
If none of them you have seen, may the sequence have been hung up. Possibly putting redflag3.md on top of your vault and restarting obsidian may help us. (This means that reset the local database and fetching from the remote without UI).
When finally not worked, If possible, could you please try another CouchDB instance without SSL configuration on it for testing? (I am using fly.io for testing).

Sorry and thank you for your patience.

@Sirtz
However, this time when I opened Obsidian, it showed the following log, and after fetching and crashing again at around 1500 downloads, it displayed the same error. Since this is the first time I've encountered this log, I'm not sure if it's related to the current issue.

Additionally, I think SSL should not be an issue, as on my server, there are two repositories in the same CouchDB instance used for syncing Obsidian, and the other repository works fine on both iOS and Windows.However, their sync plugin settings are different.

Hello, I've conducted a few simple tests. At first, I thought it was because my app wasn't completely removed, so I thoroughly cleared all cache data and reinstalled Obsidian. However, when I tried to fetch server data using the "copy URL" method, the Obsidian crash issue I mentioned before reappeared. Obsidian displayed a black screen, then reloaded the app, and the synchronization was interrupted.
I suspect that after this interruption, some dirty data was generated, which led to the fetch failure issue I mentioned earlier.
However, I do not know what caused Obsidian to crash.

Sorry for being absent for a few days!
Your information helps me, possibly memory has run out.
I am sorry you have tried so many times, could you please try once again with Read chunks online enabled? It may reduce the number of chunks and documents waiting.
Possibly enlarging Chunk size works for this, however, it requires rebuilding.

Thank you too for your patience!
We can see the log by the document box icon on our ribbon.
However, conflicted files can be picked up by Pick a file to resolve conflict. It might be an easier way.

Oh, Thank you, I didn't even notice this feature before. I should have submitted the log when reporting the issue earlier. I apologize for my oversight.

Hi, I have some good news: the sync on iOS is finally working correctly. I will summarize below the simple tests I conducted and what happened during the process.
First, I tried enabling the "Read chunks online" feature and set the "Chunks Size" to 100. After this, I attempted to fetch, but my Obsidian still showed the same error as before.Even after adjusting the "Chunks Size" to 200, it still didn't work.
After rebuilding my database, I enabled "Read chunks online" on my iPhone and set the "Chunks Size" to 100, then tried to fetch again. This time, my Obsidian relaunched itself once, and then attempted to relaunch again. However, the second relaunch failed and the screen remained black. I closed Obsidian and reopened the app, then turned on "Livesync." Miraculously, it fetched all the data from the server, and since then, Obsidian has not relaunched again.
On my iPad, I also set up the chunks and fetched server data. However, the iPad didn't encounter any relaunch issues.
So, it seems that the rebuild worked, but I don't know why, and I don't know why my iOS devices suddenly encountered this issue during use and required a rebuild. As for my iPhone's relaunch and black screen issue, I think it might be due to insufficient memory, but I'm not entirely sure about the specifics.
In summary, thank you for your help. The issue on my iOS devices has been resolved, and this is a great plugin.I would like to buy you a coffee

Additionally, I have another question. After using the chunks size feature, my Livesync has become very slow. If increasing the size can solve this issue, is there a recommended size?

Thank you for your great patience and for trying so many things!
I still think that it has been caused by out-of-memory for some chunks.
Chunk size controls how binary files are split. If too finely divided, it takes longer to wait. Conversely, if they are split too large divided, it takes longer to collect them. Therefore, it may depend on the type and number of files. This is just my guess, but maybe it can be balanced at around 50.
May I ask which process has slowed down? (Show status inside editor will help us).
One more thing, once the vault has been synchronised, we can safely disable Read chunks online relative to initial synchronisation. Will this improve the situation?
However, possibly we need a safety relief valve for fetching and synchronisation.

Yes, but I found that the issue is not with the chunk size. It seems that there is a slight problem with Livesync on iOS. When I enable Livesync on iOS, the documents I modify on my PC are not updated in real-time on my iOS devices. The synchronization only happens when I reopen Obsidian, but it could be due to some of my settings.
Regardless, the issue was resolved when I turned off Livesync and switched to another sync method. I appreciate your patience, and I will close this issue.


x/net/http2: pool deadlock

What version of Go are you using (go version)?

go version go1.12.4 freebsd/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
GOARCH="amd64"
GOBIN="/data/go/bin"
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH="/data/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build232080061=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Use the net/http client to make requests to an http2 supporting server.
What did you expect to see?
Requests should continue to succeed if a single connection becomes blocked in a write.
What did you see instead?
A single blocked connection prevented new http2 connections from being established due to the http2 pool requiring the connection lock when testing to see if an existing connection can handle new requests. This results in the entire application hanging indefinitely.
The following trace was created with an older go version 1.9 from our production app, but I have proved it's still possible to reproduce in the latest version as detailed above, as the locking between connections and pool haven't been changed.
-- goroutine blocked in writeHeaders -> Flush
1 @ 0x43bddc 0x436eea 0x4364e7 0x4a201e 0x4a210d 0x4a3a04 0x577812 0x589dbd 0x5d1887 0x5d1da0 0x5d2cbb 0x662cea 0x6ad1d4 0x52bdce 0x6678dc 0x66680b 0x663215 0x662dda 0x6476b9 0x690a17 0x63b819 0x63b4ad 0x63cb4d 0xb1d000 0xe641df 0xe6213e 0xe8245c 0xe7f42e 0xe7ad28 0xe61e87 0xf598ed 0xf59637
#    0x4364e6    internal/poll.runtime_pollWait+0x56                                                    /usr/local/go/src/runtime/netpoll.go:173
#    0x4a201d    internal/poll.(*pollDesc).wait+0xad                                                    /usr/local/go/src/internal/poll/fd_poll_runtime.go:85
#    0x4a210c    internal/poll.(*pollDesc).waitWrite+0x3c                                                /usr/local/go/src/internal/poll/fd_poll_runtime.go:94
#    0x4a3a03    internal/poll.(*FD).Write+0x243                                                        /usr/local/go/src/internal/poll/fd_unix.go:227
#    0x577811    net.(*netFD).Write+0x51                                                            /usr/local/go/src/net/fd_unix.go:220
#    0x589dbc    net.(*conn).Write+0x6c                                                            /usr/local/go/src/net/net.go:188
#    0x5d1886    crypto/tls.(*Conn).write+0x1a6                                                        /usr/local/go/src/crypto/tls/conn.go:832
#    0x5d1d9f    crypto/tls.(*Conn).writeRecordLocked+0x35f                                                /usr/local/go/src/crypto/tls/conn.go:909
#    0x5d2cba    crypto/tls.(*Conn).Write+0x1ba                                                        /usr/local/go/src/crypto/tls/conn.go:1068
#    0x662ce9    net/http.http2stickyErrWriter.Write+0x79                                                /usr/local/go/src/net/http/h2_bundle.go:6803
#    0x6ad1d3    net/http.(*http2stickyErrWriter).Write+0x73                                                <autogenerated>:1
#    0x52bdcd    bufio.(*Writer).Flush+0x7d                                                        /usr/local/go/src/bufio/bufio.go:567
#    0x6678db    net/http.(*http2ClientConn).writeHeaders+0x1eb                                                /usr/local/go/src/net/http/h2_bundle.go:7436
#    0x66680a    net/http.(*http2ClientConn).RoundTrip+0x46a                                                /usr/local/go/src/net/http/h2_bundle.go:7289
#    0x663214    net/http.(*http2Transport).RoundTripOpt+0x144                                                /usr/local/go/src/net/http/h2_bundle.go:6858
#    0x662dd9    net/http.(*http2Transport).RoundTrip+0x39                                                /usr/local/go/src/net/http/h2_bundle.go:6820
#    0x6476b8    net/http.http2noDialH2RoundTripper.RoundTrip+0x38                                            /usr/local/go/src/net/http/h2_bundle.go:990
#    0x690a16    net/http.(*Transport).RoundTrip+0xd46                                                    /usr/local/go/src/net/http/transport.go:371
#    0x63b818    net/http.send+0x1a8                                                            /usr/local/go/src/net/http/client.go:249
#    0x63b4ac    net/http.(*Client).send+0xfc                                                        /usr/local/go/src/net/http/client.go:173
...

-- goroutine waiting for connection lock, held above, while holding the pool lock
1 @ 0x43bddc 0x43bece 0x44d2c4 0x44cfdd 0x48115e 0x66546f 0x6457d8 0x646dce 0x6631c7 0x662dda 0x6476b9 0x690a17 0x63b819 0x63b4ad 0x63cb4d 0xb1d000 0xe641df 0xe6213e 0xe8245c 0xe7f42e 0xe7ad28 0xe61e87 0xf598ed 0xf59637 0x46b1f1
#    0x44cfdc    sync.runtime_SemacquireMutex+0x3c                                                    /usr/local/go/src/runtime/sema.go:71
#    0x48115d    sync.(*Mutex).Lock+0xed                                                            /usr/local/go/src/sync/mutex.go:134
#    0x66546e    net/http.(*http2ClientConn).CanTakeNewRequest+0x3e                                            /usr/local/go/src/net/http/h2_bundle.go:7083
#    0x6457d7    net/http.(*http2clientConnPool).getClientConn+0xe7                                            /usr/local/go/src/net/http/h2_bundle.go:739
#    0x646dcd    net/http.http2noDialClientConnPool.GetClientConn+0x4d                                            /usr/local/go/src/net/http/h2_bundle.go:927
#    0x6631c6    net/http.(*http2Transport).RoundTripOpt+0xf6                                                /usr/local/go/src/net/http/h2_bundle.go:6852
#    0x662dd9    net/http.(*http2Transport).RoundTrip+0x39                                                /usr/local/go/src/net/http/h2_bundle.go:6820
#    0x6476b8    net/http.http2noDialH2RoundTripper.RoundTrip+0x38                                            /usr/local/go/src/net/http/h2_bundle.go:990
#    0x690a16    net/http.(*Transport).RoundTrip+0xd46
...

-- goroutines blocked waiting for the pool lock held above
13033 @ 0x43bddc 0x43bece 0x44d2c4 0x44cfdd 0x48115e 0x645754 0x646dce 0x6631c7 0x662dda 0x6476b9 0x690a17 0x63b819 0x63b4ad 0x63cb4d 0xb1d000 0xe641df 0xe6213e 0xe8245c 0xe7f42e 0xe7ad28 0xe61e87 0xf598ed 0xf59637 0x46b1f1
#   0x44cfdc    sync.runtime_SemacquireMutex+0x3c                                                   /usr/local/go/src/runtime/sema.go:71
#   0x48115d    sync.(*Mutex).Lock+0xed                                                         /usr/local/go/src/sync/mutex.go:134
#   0x645753    net/http.(*http2clientConnPool).getClientConn+0x63                                          /usr/local/go/src/net/http/h2_bundle.go:737
#   0x646dcd    net/http.http2noDialClientConnPool.GetClientConn+0x4d                                           /usr/local/go/src/net/http/h2_bundle.go:927
#   0x6631c6    net/http.(*http2Transport).RoundTripOpt+0xf6                                                /usr/local/go/src/net/http/h2_bundle.go:6852
#   0x662dd9    net/http.(*http2Transport).RoundTrip+0x39                                               /usr/local/go/src/net/http/h2_bundle.go:6820
#   0x6476b8    net/http.http2noDialH2RoundTripper.RoundTrip+0x38                                           /usr/local/go/src/net/http/h2_bundle.go:990
#   0x690a16    net/http.(*Transport).RoundTrip+0xd46                                                   /usr/local/go/src/net/http/transport.go:371
#   0x63b818    net/http.send+0x1a8                                                         /usr/local/go/src/net/http/client.go:249
#   0x63b4ac    net/http.(*Client).send+0xfc                                                        /usr/local/go/src/net/http/client.go:173
#   0x63cb4c    net/http.(*Client).Do+0x28c                                                     /usr/local/go/src/net/http/client.go:602

This is similar to #23559 however that bug is specifically about certain areas of the http2 connections not paying attention to timeouts whereas this bug is caused by the interaction of individual connection locks and the pool lock.

CC @bradfitz @tombergan

Whelp....
        // TODO(bradfitz): this Flush could potentially block (as
        // could the WriteHeaders call(s) above), which means they
        // wouldn't respond to Request.Cancel being readable. That's
        // rare, but this should probably be in a goroutine.
        cc.bw.Flush()
        return cc.werr
}

I haven't reviewed CL 179938 but it seems a bit long/invasive.  I wonder why the mutex needs to be held during that write.
Rather than change everything so CanTakeRequest can work without taking the lock, can we instead not hold the lock during the write and not modify CanTakeRequest?

I tried that but because cc.bw.Write(...) modifies cc.werr it requires the lock.
It may be that adding a lock just around the update of werr would be possible but given the wide scope of the current lock, it would hard to prove it's not needed elsewhere too.

There seems to be a mix of ways the locks are acquired but it is always mu then wmu. I can see value in acquiring wmu under mu and then releasing if we are trying to guarantee some ordering.
I didn't submit any CL because I am lacking a testcase that shows the issue. When I try the testcase in the submitted CL, it fails the same way using the current code as well as when I move the lock.
If I just glance at the testcase, I don't see how this is testing the right behavior. The server is closed after the first connection and we are only allowed 1 dial, so the second request fails with too many dials.

The test only talks to one endpoint so the http/2 code will try to make these requests over the same TCP connection; it's designed to validate that the first request doesn't block the second request due to a stalled write; in this situation, it should just create a new connection but as the CanTakeRequest blocks it can't do that.
You are correct in that mu is always acquired before wmu if holding both as documented here:
https://github.com/golang/net/blob/master/http2/transport.go#L240

@fraenkel Thanks so much for helping fix this bug! We've run into this quite a few times on some service to service calls under specific conditions

@fraenkel Thanks for this patch https://golang.org/cl/240338, I've manually applied the patch and the issue is gone. Can we have this merged so I can remove the manual patch?

Any update on this @fraenkel? This patch: https://golang.org/cl/240338 has been working great for me in production for the last 2 months

I believe this may be tangential which was resolved in 1.15.3 https://github.com/golang/go/issues/42113

Given the description of that bug says "will cause all subsequent write requests to fail blindly" I think this is very different as its a definite deadlock.

@fraenkel Thanks for this patch https://golang.org/cl/240338, I've manually applied the patch and the issue is gone. Can we have this merged so I can remove the manual patch?

@fraenkel Thanks for this patch , will this patch merger into master ?

Thank you for fixing this issue. It has have been affecting us for quite some time. Is it possible to merge the solution to a 1.17 point release? Or we have to wait for 1.18?

@gopherbot Please open backport issues.
This appears to be an occasional deadlock in http.  Should be considered for backporting depending on what @neild thinks.


my PHP (Laravel) app was detected as Node.js

my root directory
Procfile
artisan
composer.json
config
gulpfile.js
phpspec.yml
public
resources
storage
app
bootstrap
composer.lock
database
package.json
phpunit.xml
readme.md
server.php
tests

how can I undo all that and force Flynn to detect it as PHP?

It's being detected as Node.JS because of package.json being present in the root.
You can either set the build pack explicitly with this command:
flynn env set BUILDPACK_URL "https://github.com/heroku/heroku-buildpack-php"
Or you could exclude package.json from the slug compilation stage by creating a .slugignore file in the root of your application that contains:
package.json

@josephglanville Okay, but how to install & build npm dependies with composer dependies? My app have an frontend and backend in the same directory and php-buildpack can't works properly. One way to exit, it to fork php-buildpack repository and add these option himself?

If I'll to create .buildpacksfile and add two two buildpacks: node and php. It should be install Node dependencies and composer dependencies? Right?