arloader
arloader copied to clipboard
CalebEverett
StatusNotOK
Hi. i need to upload an json file to arweave with rust(im using arloader = "0.1.63"). but i got a StatusCodeNotOk error.
it makes empty folder (ex: SZ2g5l-q7M4) and after an error the folder is deleted by itself.
Also it takes fee, even with error StatusCodeNotOk:
but with CLI everything is ok, no errors.
arloader upload xxx.json --with-sol --sol-keypair-path /Users/x/.config/solana/id.json --ar-default-keypair
Any ideas why?
Error:
thread 'main' panicked at '----- err: status code not ok', src/upload_files_2.rs:199:21
stack backtrace:
0: 0x10b4b9ef4 - std::backtrace_rs::backtrace::libunwind::trace::hc513dadde6954c86
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x10b4b9ef4 - std::backtrace_rs::backtrace::trace_unsynchronized::hef5b528e06275835
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x10b4b9ef4 - std::sys_common::backtrace::_print_fmt::hd90f3854346e0ebc
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:66:5
3: 0x10b4b9ef4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h85521558a183f368
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:45:22
4: 0x10b4d509b - core::fmt::write::h01631fae0d2b98bc
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/fmt/mod.rs:1197:17
5: 0x10b4b4ab8 - std::io::Write::write_fmt::h675dde99a2999169
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/io/mod.rs:1672:15
6: 0x10b4bb89d - std::sys_common::backtrace::_print::h9f1d91ee7cd2be55
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:48:5
7: 0x10b4bb89d - std::sys_common::backtrace::print::h4ad640f11cc29383
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:35:9
8: 0x10b4bb89d - std::panicking::default_hook::{{closure}}::h5e5df492d229fd65
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:295:22
9: 0x10b4bb5f4 - std::panicking::default_hook::h18647b59f1a84ee2
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:314:9
10: 0x10b4bbdd8 - std::panicking::rust_panic_with_hook::hd9ead35a68ccc55e
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:698:17
11: 0x10b4bbd13 - std::panicking::begin_panic_handler::{{closure}}::h6fca91c5e1dc2f30
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:588:13
12: 0x10b4ba377 - std::sys_common::backtrace::__rust_end_short_backtrace::h4ff3025d9a0a0490
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:138:18
13: 0x10b4bb9ea - rust_begin_unwind
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
14: 0x10b4efbb3 - core::panicking::panic_fmt::h3d9f795ee387ef8d
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
15: 0x10ab37cc2 - nft_metadata::upload_files_2::test_upload_file_from_path_with_sol::{{closure}}::hb8fe6cce227e8978
at /Users/viktor/SolanaWorkspace/nft-metadata/src/upload_files_2.rs:199:21
16: 0x10ab27497 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::he32511af53025e80
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/future/mod.rs:91:19
17: 0x10ab0cb01 - tokio::park::thread::CachedParkThread::block_on::{{closure}}::hf98dcba3d89e9394
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/park/thread.rs:263:54
18: 0x10aaf43e8 - tokio::coop::with_budget::{{closure}}::h8f3cef8a0094aa0a
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/coop.rs:106:9
19: 0x10aafbf0e - std::thread::local::LocalKey<T>::try_with::h2592c78968e826ec
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/thread/local.rs:445:16
20: 0x10aafbcb4 - std::thread::local::LocalKey<T>::with::h7a0b1186cdee89b9
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/thread/local.rs:421:9
21: 0x10ab0c4de - tokio::coop::with_budget::h60f98d0ff60a035c
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/coop.rs:99:5
22: 0x10ab0c4de - tokio::coop::budget::h8e386e495c4b0c28
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/coop.rs:76:5
23: 0x10ab0c4de - tokio::park::thread::CachedParkThread::block_on::h0c7bb7f1c9c5cfbe
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/park/thread.rs:263:31
24: 0x10ab0adcd - tokio::runtime::enter::Enter::block_on::h41508e85a19c1a26
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/enter.rs:151:13
25: 0x10aaf2eef - tokio::runtime::thread_pool::ThreadPool::block_on::h55293f9165436576
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/thread_pool/mod.rs:77:9
26: 0x10ab2d520 - tokio::runtime::Runtime::block_on::h78e12c21ffd62b54
at /Users/viktor/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/mod.rs:463:43
27: 0x10ab1d180 - nft_metadata::upload_files_2::test_upload_file_from_path_with_sol::hb8917331bc9bc0dc
at /Users/viktor/SolanaWorkspace/nft-metadata/src/upload_files_2.rs:208:5
28: 0x10ab0aa09 - nft_metadata::main::he3f7432529c9137b
at /Users/viktor/SolanaWorkspace/nft-metadata/src/main.rs:33:13
29: 0x10aaff68e - core::ops::function::FnOnce::call_once::h2886063610811728
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5
30: 0x10aafc821 - std::sys_common::backtrace::__rust_begin_short_backtrace::hac21c6f8c37f6631
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:122:18
31: 0x10ab1c924 - std::rt::lang_start::{{closure}}::hab33639a50e1c439
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:145:18
32: 0x10b4af28e - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h7b036f15aca60adb
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:280:13
33: 0x10b4af28e - std::panicking::try::do_call::hf6119ec0466800e8
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:492:40
34: 0x10b4af28e - std::panicking::try::hcda27a2b6f836f01
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:456:19
35: 0x10b4af28e - std::panic::catch_unwind::hde37ab35642f072b
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panic.rs:137:14
36: 0x10b4af28e - std::rt::lang_start_internal::{{closure}}::h103d9f9a51ce5b21
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:128:48
37: 0x10b4af28e - std::panicking::try::do_call::h0e10440d51723322
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:492:40
38: 0x10b4af28e - std::panicking::try::h738bcf26bd63f912
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:456:19
39: 0x10b4af28e - std::panic::catch_unwind::hc9eba21b74d8966b
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panic.rs:137:14
40: 0x10b4af28e - std::rt::lang_start_internal::h3fd5cff071397f19
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:128:20
41: 0x10ab1c8fe - std::rt::lang_start::h40d9b716e1344c4c
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/rt.rs:144:17
42: 0x10ab0aa36 - _main
cod005hctln:src viktor$
my code:
use arloader::{
error::Error,
solana::{SOLANA_MAIN_URL, SOL_AR_BASE_URL},
utils::TempDir,
Arweave,
};
use solana_sdk::signer::keypair;
use std::{path::PathBuf, str::FromStr};
use url::Url;
async fn get_arweave() -> Result<Arweave, Error> {
let ar_keypair_path = PathBuf::from("/Users/viktor/SolanaWorkspace/arweave-key-CAJ7UsUYpeRAp4gb8-mm9k-6a2H8XEWTPQeGYzuFSOU.json");
let arweave = match Arweave::from_keypair_path(
ar_keypair_path,
Url::from_str("https://arweave.net").unwrap(),
)
.await
{
Ok(arweave) => arweave,
Err(e) => panic!("----- arweave error: {}", e),
};
Ok(arweave)
}
#[tokio::main]
pub async fn upload_file_with_sol() -> Result<(), Error> {
let solana_url = SOLANA_MAIN_URL.parse::<Url>()?;
let sol_ar_url = SOL_AR_BASE_URL.parse::<Url>()?.join("sol")?;
let keypair = PathBuf::from("/Users/viktor/.config/solana/id.json");
println!("{}", keypair.exists());
let from_keypair = keypair::read_keypair_file("/Users/viktor/.config/solana/id.json")?;
let arweave = get_arweave().await?;
let file_path = PathBuf::from("tests/fixtures/1.json");
let temp_log_dir = TempDir::from_str("tests/fixtures/").await?;
let log_dir = temp_log_dir.0.clone();
println!("------- solana_url: {}", solana_url);
println!("------- sol_ar_url: {}", sol_ar_url);
println!("------- file_path: {:?}", &file_path);
println!("{}", file_path.exists());
println!("------- log_dir: {:?}", log_dir);
println!("{}", log_dir.exists());
let status = arweave
.upload_file_from_path_with_sol(
file_path.clone(),
None,
None,
None,
(0, 0), // (5,5) doesn't work either
solana_url.clone(),
url::Url::parse("https://arloader.io/sol").unwrap(),
&from_keypair,
)
.await;
match status {
Ok(x) => x,
Err(err) => panic!("----- err: {:#}", err),
};
// println!("{:?}", status);
let read_status = arweave.read_status(file_path, log_dir.clone()).await?;
println!("{:?}", &read_status);
Ok(())
}
HI Ros, I'll check this out today.
On Mon, Aug 22, 2022 at 5:34 AM Ros Mc Mahon @.***> wrote:
@CalebEverett https://github.com/CalebEverett
— Reply to this email directly, view it on GitHub https://github.com/CalebEverett/arloader/issues/32#issuecomment-1222297081, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEIMQZJY4HT3UOOMYD76ODV2NXXFANCNFSM567EURGA . You are receiving this because you were mentioned.Message ID: @.***>
hi @CalebEverett thanks for the package :), i'm also getting this error
trying to execute this cmd:
arloader upload ceremonio_dj_001.png --with-sol --sol-keypair-path ~/code/dapps/realidad/nft-meta/CRMiUZVfwiw7PB6MSpiVEja6wC6o6ombPJLzdwRn6y4C.json --ar-default-keypair --no-bundle
after a while the fee is sent but an error is returned:
StatusCodeNotOk
<FILE_PATHS> didn't match any files.
any idea what is going on?
Working on a fix
On Tue, Aug 23, 2022, 2:08 PM erikiado @.***> wrote:
hi @CalebEverett https://github.com/CalebEverett thanks for the package :), i'm also getting this error
trying to execute this cmd: arloader upload ceremonio_dj_001.png --with-sol --sol-keypair-path ~/code/dapps/realidad/nft-meta/CRMiUZVfwiw7PB6MSpiVEja6wC6o6ombPJLzdwRn6y4C.json --ar-default-keypair --no-bundle
after a while the fee is sent but an error is returned:
StatusCodeNotOk <FILE_PATHS> didn't match any files.
any idea what is going on?
— Reply to this email directly, view it on GitHub https://github.com/CalebEverett/arloader/issues/32#issuecomment-1224888502, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEIMQ6ZEPKR6D4CXTFA4SLV2U4TJANCNFSM567EURGA . You are receiving this because you were mentioned.Message ID: @.***>
hey @CalebEverett!
Thanks for this CLI. I managed to upload multiple times without any issue, but for two days now it fails.
When using upload-nfts I get:
Uploading assets...
Uploading 1 files with 3740 KB of data in 1 bundle transactions...
StatusCodeNotOk
Uploaded 0 KB in 0 files in 0 bundle transaction(s). Run `arloader update-status ./arloader_J_H9Ad4ksaa/assets/` to update statuses.
Uploading manifest for images...
No bundle statuses found in ./arloader_J_H9Ad4ksaa/assets/
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/m/.asdf/installs/rust/1.50.0/registry/src/github.com-1ecc6299db9ec823/arloader-0.1.63/src/commands.rs:802:6
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
and when using upload
StatusCodeNotOk
<FILE_PATHS> didn't match any files.
all commands are executed with --with-sol and both bundle and no bundle fail.
Do you have an idea of the issue?
Working on a fix … On Tue, Aug 23, 2022, 2:08 PM erikiado @.> wrote: hi @CalebEverett https://github.com/CalebEverett thanks for the package :), i'm also getting this error trying to execute this cmd: arloader upload ceremonio_dj_001.png --with-sol --sol-keypair-path ~/code/dapps/realidad/nft-meta/CRMiUZVfwiw7PB6MSpiVEja6wC6o6ombPJLzdwRn6y4C.json --ar-default-keypair --no-bundle after a while the fee is sent but an error is returned: StatusCodeNotOk <FILE_PATHS> didn't match any files. any idea what is going on? — Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEIMQ6ZEPKR6D4CXTFA4SLV2U4TJANCNFSM567EURGA . You are receiving this because you were mentioned.Message ID: @.>
Hello :) I'm stuck with this issue too and I'm trying to debug it, so I was curious if you ended up finding the problem or any clues on it.
I don't call the CLI but use the library on my own project, and calling upload_file_from_path with certain files makes the arweave HTTP api return 400 and thus returns StatusCodeNotOk.
~~During the tests I found out that it fails when you try to upload files above 250KiB, which is the maximum chunk size. So my guess is that when the library has to split the file in >1 chunks, something goes wrong and the transaction ends up incorrectly built.~~ I thought it was after 250KiB but it seems that is not the case, as I crafted a file of 268KiB that fails to upload, but another of 300KiB that uploads correctly.
So right now I'm debugging and testing the transaction generation and in particular the merklize function. But I'm not familiar at all with the arweave serialization steps and merklee trees in general so I'm a bit lost x)
I'll keep digging, but if you have any clues of when you researched it, they would be appreciated!
I haven't had time to properly diagnose this. I didn't think it was in the chunking. I thought it was in the transaction submission. My next step was to get better error reporting working, i.e. instead of just reporting status not ok, get the response code from Arweave and any returned error messages to see what it is saying. I could be wrong, but the chunking was pretty well tested.
On Thu, Jan 5, 2023, 2:04 AM nF0x @.***> wrote:
Working on a fix … <#m_315106686319716942_> On Tue, Aug 23, 2022, 2:08 PM erikiado @.> wrote: hi @CalebEverett https://github.com/CalebEverett https://github.com/CalebEverett https://github.com/CalebEverett thanks for the package :), i'm also getting this error trying to execute this cmd: arloader upload ceremonio_dj_001.png --with-sol --sol-keypair-path ~/code/dapps/realidad/nft-meta/CRMiUZVfwiw7PB6MSpiVEja6wC6o6ombPJLzdwRn6y4C.json --ar-default-keypair --no-bundle after a while the fee is sent but an error is returned: StatusCodeNotOk <FILE_PATHS> didn't match any files. any idea what is going on? — Reply to this email directly, view it on GitHub <#32 (comment) https://github.com/CalebEverett/arloader/issues/32#issuecomment-1224888502>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEIMQ6ZEPKR6D4CXTFA4SLV2U4TJANCNFSM567EURGA https://github.com/notifications/unsubscribe-auth/ACEIMQ6ZEPKR6D4CXTFA4SLV2U4TJANCNFSM567EURGA . You are receiving this because you were mentioned.Message ID: @.>
Hello :) I'm stuck with this issue too and I'm trying to debug it, so I was curious if you ended up finding the problem or any clues on it.
I don't call the CLI but use the library on my own project, and calling upload_file_from_path with certain files makes the arweave HTTP api return 400 and thus returns StatusCodeNotOk.
During the tests I found out that it fails when you try to upload files above 250KiB, which is the maximum chunk size. So my guess is that when the library has to split the file in >1 chunks, something goes wrong and the transaction ends up incorrectly built.
So right now I'm debugging and testing the transaction generation and in particular the merklize function. But I'm not familiar at all with the arweave serialization steps and merklee trees in general so I'm a bit lost x)
— Reply to this email directly, view it on GitHub https://github.com/CalebEverett/arloader/issues/32#issuecomment-1372012371, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEIMQ5GLXTACMIR2AAP4B3WQ2MA7ANCNFSM567EURGA . You are receiving this because you were mentioned.Message ID: @.***>
Hey, thanks for the answer! You seem to be correct on that, I modified the function to always take the /chunk endpoint route instead of the /tx endpoint route, and suddently I can upload files of any size without issue.
I tried to get what error the /tx endpoint was returning, but it seems that it returns a 400 with an empty body. The API docs don't specify any possible error message on the tx endpoint neither, so... :)
For now I need to finish this thing I'm working on 😓 , but I'll try to dig up the reason later and I'll submit a PR if I find it, thanks again for the help!
Thanks for trying that out - I'll see about moving everything over to the chunk endpoint. I haven't been following along closely, but it may be that the size limit on the tx enpoint changed and the threshold in arloader is now too high.
@CalebEverett Currently facing this problem when running following command in my shell:
echo '{
"name": "",
"symbol": "",
"description": "",
"image": ""
}' > metadata.json
arloader upload metadata.json --with-sol --sol-keypair-path ~/.config/solana/id.json --ar-default-keypair --no-bundle
Retrying Solana transaction (1 of 10)...
Retrying Solana transaction (2 of 10)...
StatusCodeNotOk
<FILE_PATHS> didn't match any files.
