Issue with dispatch on worker process

[traktofon]

While trying to make DistributedArrays.jl work on julia-0.7, I got stuck at a strange test failure which AFAICT is due to a function getting dispatched to the wrong method on the worker process.

To reproduce, please use my for07 branch:

pkg> dev https://github.com/traktofon/DistributedArrays.jl.git#for07

and run the following code:

using Distributed
addprocs(2)
@everywhere using DistributedArrays
D=drand((200,200),[1,2]);
fetch(@spawnat 1 size(localpart(D)))
# -> (200, 100)
fetch(@spawnat 2 size(localpart(D)))
# -> (200, 200) # should be (200, 100) as on pid 1
fetch(@spawnat 1 typeof(D))
# -> DArray{Float64,2,Array{Float64,2}}
fetch(@spawnat 2 typeof(D))
# -> DArray{Float64,2,Array{Float64,2}} # same as on pid 1
fetch(@spawnat 1 @which localpart(D))
# localpart(d::DArray{T,N,A}) where {T, N, A} in DistributedArrays at .../src/darray.jl:327
fetch(@spawnat 2 @which localpart(D))
# localpart(A) in DistributedArrays at .../src/core.jl:65 # this is the wrong method

On julia-0.6, the upstream DistributedArrays.jl dispatches the localpart function to the correct method on all workers. Note that I didn't change the localpart method signatures in my modifications.

I'm wondering whether this can be fixed inside the package, but I don't see how to influence the dispatch, seeing that the type of D appears to be the same on all workers. Or is it an issue in julia?

Obligatory versioninfo:

Julia Version 0.7.0-beta.276
Commit 70bd2c2116 (2018-07-12 12:55 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, skylake)

[traktofon]

Oh. If I execute using DistributedArrays between using Distributed and addprocs(2) (but still do @everywhere using DistributedArrays later), then this doesn't happen and the dispatch works correctly. Is this expected behavior? I must admit I'm utterly puzzled now.

[traktofon]

This no longer seems to apply to Julia 1.x since the release of 1.0. Therefore closing.